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.
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.