MonticelloFileTree-Git dirties Metacello-Core package ...

[dalehenrich]

The current implementation of MetacelloPlatform>>createRepository stomps on an existing method in the Metacello code base and is of course not recommended ...

First choice would be to extend Metacello to support the gitfiletree:// scheme, but since Pharo doesn't necessarily track the latest Metacello changes it might be a long time before the package was actually loaded into the image.

Second choice is to move the method to MetacelloPharo30Platform>>createRepository ... there is no current implementation of that method, so it would be a clean extension .... also perhaps there could be a coordinated move of the method from FileTree to to Metacello for 6.0 which would provide for some slippage ...

I'll have a pull request for the Second Choice very soon ...

[dalehenrich]

@ThierryGoubier is looks like you have been using metadataless GitFileTree to manage this repository (based on the dates that the methodProperties files were last touched), but when I looked at .filetree I didn't see the "Metadata" : "false", so I assumed that you were still recording metadata, especially since the files were all still there ... it wasn't until I committed that it became obvious ...

In the GemStone version of FileTree, I can't afford to assume that the default for "Metadata" is false, so perhaps you should make sure that "Metadata" : "false" gets written to the .filetree file?

[ThierryGoubier]

@dalehenrich it doesn't seems like the effect of the metadata-less mode of GitFileTree, but like an effect of GitFileTree in metadata mode not to use the existing method properties, but to rewrite the method properties with the timestamp of the last git commit...

Kind of saying the metadata mode of GitFileTree wasn't that great in the first place :(

[dalehenrich]

@ThierryGoubier, I am very pleased that you headed down this route ... truly! From the very beginning of FileTree there was tension to go metadataless and I think that I imagined it to be a bigger project ... the metadata files are a big pain to have when you are using GitHub and have active collaboration and I think that you have discovered a relatively simple solution .. there are only a few things that need to be fine-tuned and they are solvable problems, so don't be discouraged

[ThierryGoubier]

@dalehenrich : I think it was important to get the git integration to work, even in an imperfect state. Now, with the perspective and a few years of use, it becomes easier to redesign / improve, and, in the mean time, it has proven itself productive enough :)

[dalehenrich]

@ThierryGoubier no kidding :) GitFileTree has really paved the way for the acceptance of git within the Pharo community! Shifting paradigms is tricky business --- incremental steps is the only way to go and the increments must make imperfect compromises to provide smooth transitions :)