On Wed, Nov 25, 2015 at 6:31 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-11-25 10:39 GMT+01:00 Skip Lentz <skip.lentz@inria.fr>:
On Nov 24, 2015, at 5:37 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Skip,
2015-11-24 17:30 GMT+01:00 Skip Lentz <skip.lentz@inria.fr>:
It would be nice to have some less metadata in the repository (or none at all), especially for merging. Method and author timestamps can be gathered from the commit information, the âversionâ fill in the monticello.meta directory is not necessary too I think, since we have the commit messages obviously..
Well, GitFileTree has all that code: - Monticello metadata extraction from git logs - Filetree without Metadata Some of the information in the meta directory is necessary (pre/post load scripts).
Where are those pre/post load scripts defined? Does anyone ever use it?
You have, in that directory:
- categories (defines the package tags, for example: https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.package...) - initializers (but it's usually empty) - package (the package name: FileTree uses that)
possibly 'preamble.st' 'postscript.st' 'preambleOfRemoval*' 'postscriptOfRemoval*' Good question, I can't find any of those and I can't even find the code writing that. Dale?
Dependencies (used by SLICEs).
What is conflict-prone with git in that repository: - version
Now, removing the entire directory for a single file...
You can see the diffs of a metadata-less repository if you look at the recent commits of https://github.com/ThierryGoubier/AltBrowser/commits/pharo5
I think having a FileTree reader/writer that is not coupled to Monticello would be good, but maybe Iâm saying something that is not possible.
No, it is possible (everything is), but a bit complex for maintenance (how do you track changes and corrections in the FileTree code?).
Of course, the sky is the limit :P. Although Iâm not sure I understand what you mean here, could you explain?
FileTree has a large set of test cases, sample repositories, CI setup, cross-platform knowledge, bug fixes coming from a large group of users (far larger than the Pharo community).
Cutting ourselves from that is counter productive and looks like a case of the NIH syndrome.
Thats cool. What are the other communities? cheers -ben