[LLVMdev] git

[Andrew Trick]

On Jul 21, 2011, at 9:59 AM, Matthieu Moy wrote:

> Alexander MacDonald <alexmac at adobe.com> writes:
> 
>> The topic of generation numbers has come up again recently on the git
>> lists and it looks like they might make it in
>> (http://stackoverflow.com/questions/6702821/
>> git-commit-generation-numbers). Of course this isn't exactly the same
>> as svn because the numbers are only unique within a given branch, but
>> it should still help.
> 
> Not really. Generation numbers are discussed as a performance
> optimization, but they're not unique, even within what we usually call a
> "branch" (i.e. the set of commits reachable from the ref) :
> 
> A --- B
> \     \
>  C --- D --- E <--- master
> 
> Commits B and C will have the same generation numbers. I hardly see a
> context where they could be used by end users as commit identifiers.

SVN revision numbers are central to my workflow. I use them to tag results generated against various builds. I like those results sorted by time and the chronology should be obvious, but timestamps are incredibly cumbersome and make it difficult to verify that a given checkout matches a given set of results. For incremental development, we should have some concept of a "trunk version" number at the granularity of each build submitted for testing or benchmarking without having to constantly tag the repository.

Generation numbers seem to be sufficient for this purpose. In your example, it wouldn't make sense for B and C to have unique "trunk version" numbers because it's impossible for both of them to correspond to a build kicked off from the main repo. If C was pushed after B, then its "trunk revision" would correspond to the subsequent merge, which is the generation number of D. The only problem is checking out the right git version for a given "trunk version". Worst case, you just pick the earliest sibling, which git rev-list already seems to know.

-Andy