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. > Alright so this is odd.. Martin had the same behavior. Thank you for all >> your feedback, it’s very helpful. >> > > Maybe just an effect of the ordering (github gives you a list of > repositories, isn't it?) > > > Actually now that I think of it, it’s probably due to the fact that when > you request a list of something (e.g. list of commits, list of > repositories, etc.) the API gives you a paginated result. This means that > it will give you the first 25 repositories, and a link to retrieve the next > 25, and so on. Pagination still has to be implemented. API documentation > about pagination is here: https://developer.github.com/v3/#pagination > Ok, understood.
