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