On Wed, Nov 25, 2015 at 6:31 PM, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > > 2015-11-25 10:39 GMT+01:00 Skip Lentz <skip.le...@inria.fr>: >> >> >> On Nov 24, 2015, at 5:37 PM, Thierry Goubier <thierry.goub...@gmail.com> >> wrote: >> >> Hi Skip, >> >> 2015-11-24 17:30 GMT+01:00 Skip Lentz <skip.le...@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/monticello.meta/categories.st) > - 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
