Having a look at Git+Pharo
Hi, today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find: - there is some documentation here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include: - a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?) - a discussion about moving a smalltalkhub repository to git while preserving history - a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git. - there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests. - a list of tools missing before everyone uses git. For example: - A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
something else I forgot: - what happens if a Metacello description loads a project hosted in git but I still want to be able to hack on this dependency. So, this dependency should not be read-only for me - where to put the git repositories when images are frequently deleted and downloaded again from the launcher? What if I Pillar is hosted on github, Jenkins build Pillar images, and I want to download an image with Pillar inside? How do I link the Pillar of the image to a repository? Which repository? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
2015-09-09 16:29 GMT+02:00 Damien Cassou <damien.cassou@inria.fr>:
something else I forgot:
- what happens if a Metacello description loads a project hosted in git but I still want to be able to hack on this dependency. So, this dependency should not be read-only for me
Can you give an example?
- where to put the git repositories when images are frequently deleted and downloaded again from the launcher? What if I Pillar is hosted on github, Jenkins build Pillar images, and I want to download an image with Pillar inside? How do I link the Pillar of the image to a repository? Which repository?
Having a gitfiletree repository with an auto-clone / lazy clone option would work. When you open the repository for the first time, it clones it from where it was originally referenced. May not work transparently if there are authentification issues for the clone. Thierry
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Thierry Goubier <thierry.goubier@gmail.com> writes:
2015-09-09 16:29 GMT+02:00 Damien Cassou <damien.cassou@inria.fr>:
something else I forgot:
- what happens if a Metacello description loads a project hosted in git but I still want to be able to hack on this dependency. So, this dependency should not be read-only for me
Can you give an example?
For example, Cocoon is a framework to facilitate handling of user configuration files. We created Cocoon by extracting code from Pillar and Pillar is still the only user of Cocoon. This means we evolve Pillar and Cocoon in parallel. The configuration of Pillar requires Cocoon. As far as I understand, there are 2-ways to describe this dependency if Cocoon is hosted on github: 1. Pillar depends on a read-only version of the Cocoon source code and Metacello will download a zip archive from github. That's nice for all users of Pillar but not for Pillar developers who would prefer a read-write solution ; 2. Pillar depends on a read-write clone of the github repository. That's nice for Pillar developers but not for Pillar users. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Le 11/09/2015 06:56, Damien Cassou a écrit :
Thierry Goubier <thierry.goubier@gmail.com> writes:
2015-09-09 16:29 GMT+02:00 Damien Cassou <damien.cassou@inria.fr>:
something else I forgot:
- what happens if a Metacello description loads a project hosted in git but I still want to be able to hack on this dependency. So, this dependency should not be read-only for me
Can you give an example?
For example, Cocoon is a framework to facilitate handling of user configuration files. We created Cocoon by extracting code from Pillar and Pillar is still the only user of Cocoon. This means we evolve Pillar and Cocoon in parallel. The configuration of Pillar requires Cocoon. As far as I understand, there are 2-ways to describe this dependency if Cocoon is hosted on github:
1. Pillar depends on a read-only version of the Cocoon source code and Metacello will download a zip archive from github. That's nice for all users of Pillar but not for Pillar developers who would prefer a read-write solution ;
2. Pillar depends on a read-write clone of the github repository. That's nice for Pillar developers but not for Pillar users.
Easy: stable version of pillar has github:// reference to Cocoon baseline. Development version of pillar has gitfiletree:// reference to Cocoon baseline. Variant: ConfigurationOfPillar in catalog browser has github:// reference to Cocoon. Developpers of pillar write (Metacello baseline: 'pillar'; repository: 'gitfiletree://' ...) with a Pillar baseline referencing gitfiletree for Cocoon. Thierry
- a discussion about moving a smalltalkhub repository to git while preserving history
I've migrated some time ago http://forum.world.st/moving-to-git-and-preserving-monticello-history-td4806... some (if not all) of the issues were resolved iirc, however since I didn't need to migrate since then I don't know the current status. - a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
Please note that GitFileTree didn't reliably work under Windows (problems with ProcessWrapper or something; crashing a lot), don't know the current status. However from practical standpoint: * with GitFileTree each MC commit inside Pharo creates a Git commit, so if you change X packages within a single repo, you get also X git commits * with FileTree you could pack them together more tightly but you need to commit to git explicity. but otherwise I don't see much practical difference - what happens if a Metacello description loads a project hosted in git
but I still want to be able to hack on this dependency. So, this dependency should not be read-only for me
This is in my eyes very messy.... you could either add the package to a repository after you have loaded your project, or lock local repos... but it's quite a pain to keep everything in sync... but I didn't have time to simplify my workflow here yet. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "GitFileTree" Gofer new url: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main'; configurationOf: 'GitFileTree'; loadDevelopment. "Dependency 1" Metacello new baseline: 'Dependency1'; repository: 'gitfiletree:///home/wherever/dependency1/repository'; lock. "Dependency 2" Metacello new baseline: 'Project2'; repository: 'gitfiletree:///home/wherever/project2/repository'; lock. "My Project" Metacello new baseline: 'MyProject'; repository: 'gitfiletree:///home/wherever/myProject/repository'; onConflict: [ :ex | ex allow ]; load. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter
2015-09-09 16:43 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- a discussion about moving a smalltalkhub repository to git while
preserving history
I've migrated some time ago
http://forum.world.st/moving-to-git-and-preserving-monticello-history-td4806...
some (if not all) of the issues were resolved iirc, however since I didn't need to migrate since then I don't know the current status.
- a discussion about which process to follow in which conditions
(should I use GitFileTree or FileTree?)
Please note that GitFileTree didn't reliably work under Windows (problems with ProcessWrapper or something; crashing a lot), don't know the current status.
I don't either. I made some changes on the ProcessWrapper use, hoping for the best, but I can't test :(
However from practical standpoint: * with GitFileTree each MC commit inside Pharo creates a Git commit, so if you change X packages within a single repo, you get also X git commits * with FileTree you could pack them together more tightly but you need to commit to git explicity.
Dale has the idea of a project (grouping packages) with a single commit; however the MC API has no notion of committing multiple packages in one step except when dealing with dependencies. GitFileTree, for handling package dependencies, has a mode for writing multiple packages and commit only once, so one commit for multiple packages would be very easy to do. A special api for Versionner? Thierry
2015-09-09 16:04 GMT+02:00 Damien Cassou <damien.cassou@inria.fr>:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here:
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
Dale proposed some tools: a diff parser/reader? A reader for files with conflict markers. Thierry
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Hi! I am not sure to understand. There is a fair amount of tools for got to deal with conflict. Sure, we could imagine compelling scenarios to have the conflict merger in Pharo. But I do not feel this is that necessary for now. One question I have: is mcz the most appropriate? Why not simply doing a fileout of the package? And having one .st file per package. Alexandre Le 9 sept. 2015 à 11:38, Thierry Goubier <thierry.goubier@gmail.com> a écrit :
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Hi Alexandre, Le 10/09/2015 17:40, Alexandre Bergel a écrit :
Hi!
I am not sure to understand. There is a fair amount of tools for got to deal with conflict. Sure, we could imagine compelling scenarios to have the conflict merger in Pharo. But I do not feel this is that necessary for now.
Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly.
One question I have: is mcz the most appropriate? Why not simply doing a fileout of the package? And having one .st file per package.
You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that. Oh, by the way, for those who would like to try: git does not know how to properly merge two conflicting class definitions in the chunk format, so conflicts would still be present... But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that? Thierry
Alexandre
Le 9 sept. 2015 à 11:38, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> a écrit :
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly.
I do not see why. It works well for other languages, I see no reason why it would not work in Pharo.
One question I have: is mcz the most appropriate? Why not simply doing a fileout of the package? And having one .st file per package.
You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that.
Well, if you have git, then the baseline is rather simple right?
But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that?
What do you mean by that? What you are suggesting, is it really more than fileout a source from a package? I am probably missing something obvious here. Cheers, Alexandre
Thierry
Alexandre
Le 9 sept. 2015 à 11:38, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> a écrit :
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
Le 10/09/2015 19:37, Alexandre Bergel a écrit :
Solving MC conflicts with tools like meld isn't fun. When it is for Metacello version files, it's allmost impossible to correct properly.
I do not see why. It works well for other languages, I see no reason why it would not work in Pharo.
That's because other languages have very poor, unstructured formats which predates Smalltalk, i.e. source files. And an horrible mess of unstructured information for building it: Makefiles, configure scripts, maven, cmake, shell scripts, you name it. Anything which tries to store anything more complex under text files in git (json data, xml data, csv data) has the same problem.
One question I have: is mcz the most appropriate? Why not simply doing a fileout of the package? And having one .st file per package.
You need the mcz (in fact, Monticello) support for versions to have Metacello: configurations, baselines and all the like. I think projects like Seaside and Moose would not be doable without that.
Well, if you have git, then the baseline is rather simple right?
Yes. Part of the attractiveness of git is that: version information is moved into the repository url instead of being in the mcz name.
But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that?
What do you mean by that? What you are suggesting, is it really more than fileout a source from a package? I am probably missing something obvious here.
No, it is just a fileout. Apart from dependencies, but nobody uses them except for SLICES. There are a few queries you can do on a git repository (search for method versions, class definition changes) where you have to use the filetree format and the chunk format won't work. But, honestly, nobody needs that: I am the only user in the Pharo community (i.e. you need AltBrowser + GitFileTree for that feature). Ah, yes, for the filetree format: it's a lot easier to browse the filetree format than the chunk on github:/, bitbucket:/, gitosis, gitlab, etc... It is also reasonably portable among dialects (ST/X, Squeak, Pharo, Gemstone, VW?) But it has a problem with long file names under windows. And it may be slow to write plenty of small files. Thierry
Cheers, Alexandre
Thierry
Alexandre
Le 9 sept. 2015 à 11:38, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> a écrit :
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
Dale proposed some tools: a diff parser/reader?
A reader for files with conflict markers.
But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that is like .mcz but without all the metadata? This means that we will need another UI since Monticello will not work. Can you estimate the amount of work to do? Alexandre
Le 10/09/2015 20:29, Alexandre Bergel a écrit :
But, all well considered, relying only on the underlying vcs for versions, but writing chunk files, could it work? With the gitfiletree framework, all version / meta information is external to the source files, so Metacello could use that and have everything it needs. Would someone be interested by that?
Are you suggesting to have a different format, which could be .mcs that is like .mcz but without all the metadata?
That would be that. The mcs would be the chunk format that Pharo and all Smalltalks have (i.e. fileouts).
This means that we will need another UI since Monticello will not work.
No, it would simply be another type of repository for Monticello. I have already done the work for GitFileTree (recreate a MC-like API even if the metadata comes from git instead of the mcz), and you would reuse that. It would be totally transparent to you. Metacello, Gofer, Configurations would work.
Can you estimate the amount of work to do?
I'd start from GitFileTree, isolate the git commands and the MC API and copy them to the new repository type, add a chunk reader over a zip archive, and add the chunk writer. I'd reuse the GitFileTree repository inspector because it is already designed for that. For someone who knows a bit the internals of a MC repository, it wouldn't take long. Shouldn't forget to have a good chunk of tests cases and sample repositories: filetree would be my reference there. Thierry
Alexandre
Hi! I am confused. What is said on https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... is different than what I can read on https://github.com/ThierryGoubier/GitFileTree-MergeDriver Do I need to modify .gitattributes and .gitconfig? Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr> wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Le 11/09/2015 01:52, Alexandre Bergel a écrit :
Hi!
I am confused. What is said on https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... is different than what I can read on https://github.com/ThierryGoubier/GitFileTree-MergeDriver
In what way? The GitAndPharo chapter is a bit out of date and incomplete
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed. Thierry
Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr> wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git. More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data. Alexandre
Thierry
Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr> wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2015-09-11 15:28 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git.
Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree).
More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data.
I agree on the target, but. git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment. I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only). Thierry
Alexandre
Thierry
Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr>
wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here:
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres...
But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
But making sure that people for a given project can commit either to a git repo to a smalltalkhub significantly complexify the thing. And at the end, we will always have people who stay in smalltalkhub because it is much simpler than git. Several times I wanted to migrate to git, but the burden of Monticello metadata make me stay with SmalltalkHub. We are missing a big train⦠Alexandre
On Sep 11, 2015, at 10:35 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-09-11 15:28 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git.
Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree).
More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data.
I agree on the target, but.
git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment.
I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only).
Thierry
Alexandre
Thierry
Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr> wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This is what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2015-09-11 15:45 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
But making sure that people for a given project can commit either to a git repo to a smalltalkhub significantly complexify the thing. And at the end, we will always have people who stay in smalltalkhub because it is much simpler than git.
Of course it makes things a lot more complex. But, honestly, for anything complex (with branches and all), I would never use smalltalkhub. Not anymore. Especially given the naming bugs you have with Monticello, and the complexity of writing configurations for it.
Several times I wanted to migrate to git, but the burden of Monticello metadata make me stay with SmalltalkHub. We are missing a big trainâ¦
Not that much. The system is doing more or less fine so far. Smalltalkhub for the core, git for some of us, and it works really well. Unless you're Linus Torvalds, you don't throw your community on a new system overnight ;) Thierry
Alexandre
On Sep 11, 2015, at 10:35 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-09-11 15:28 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:
Do I need to modify .gitattributes and .gitconfig?
Just the .gitattributes. The .gitconfig stuff will be taken care of when the merge driver is installed.
Ok, but why do we need this ? What I understand is to merge conflicts with metadata of .mcz, which are useless in Git.
Yes and no. They are useless in an ideal world where everybody is using git or an equivalent (fossil, hg, svn). But they are very usefull now to get non-git users to keep using the packages (the tandem filetree/gitfiletree).
More I think about it, more I think that we need to go toward a lighter version of .mcz file, without the meta-data.
I agree on the target, but.
git support on windows is not there yet, and any format without metadata would be Linux and Mac only at the moment.
I do believe that external commands on Windows is/should be a priority, but I can only wish for it. libcgit would also solve the problem of git support (but would restrict it to git only).
Thierry
Alexandre
Thierry
Alexandre
On Sep 9, 2015, at 11:04 AM, Damien Cassou <Damien.Cassou@inria.fr>
wrote:
Hi,
today I wanted to have a look at how git integrates with Pharo. This
is
what I found (mostly done by Thierry Goubier, thank you very much) and what I didn't find:
- there is some documentation here:
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres...
But this is largely unfinished material. I contributed by adding a few things here and there but not much. If you have some experience, please share it there (https://github.com/SquareBracketAssociates/PharoInProgress). Missing things include:
- a discussion about which process to follow in which conditions (should I use GitFileTree or FileTree?)
- a discussion about moving a smalltalkhub repository to git while preserving history
- a discussion on how to write Metacello configurations for a project on git and for a project which depends on a project on git.
- there is a nice git merge driver (https://github.com/ThierryGoubier/GitFileTree-MergeDriver). It seems to work fine. I sent 3 minor pull requests.
- a list of tools missing before everyone uses git. For example:
- A tool to resolve merge conflicts in Pharo. We should reuse the diff widget we have.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Alexandre Bergel -
Damien Cassou -
Peter Uhnák -
Thierry Goubier