2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:

The problem I found is that in order to recreate sequential numbers, you have to load all commits into the image.��

Why? GitFileTree doesn't need to do that at all! Well, you know the code: it just ask git log to rebuild the parent / child relations for a package directory, and that is all... Then, like a mcz, the package isn't loaded into the image unless you select it in the GUI. So why did you need to load all the commits?

Well, at the beginning, I was trying to read all the filetree metadata stored in the repository to build the versions as if it was mczs... and that was a really bad idea (slow parser for version files, hundred of files to scan, many files were even unreadable/broken by conflicts leftovers in the filetree repository).

Yes you are right, I expressed myself badly. You don't have to load "the commits".

But, you still have to create an MCVersionInfo for each version of the package in the repository.��

In fact... you can create them, it will not kill you, but I think that this structure is not so useful, because it is always faster to use log/revwalk to ask about the relationship between two versions/commits.

Moreover, we do not want to think about packages too much, we prefer to think in terms of a whole project, so the most interesting concept for us is the commit and not the version. Therefore, when I build a history (sometimes I do) I create a graph of commits and not a graph of versions.

Finally, this leads to that, even in the case you want to load a specific version of a specific pacakge (which is not the normal case for Iceberg), you would specify a commitish (+ a package name) and not a version name.