llvm dev - Jul 2011 - [LLVMdev] git

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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

Andrew Trick <atrick at apple.com> writes:
> 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,
This means in the presence of branches, you want the ordering to be

[branch A] build 1
[branch B] build 2
[branch A] build 3
[branch C] build 4

?

It seems to me that your solution works only if you have a very simple
branch topology, where you can essentially consider branches in
isolation. As soon as you consider non-trunk branches and merge commits
to be important, the history is a DAG, and the problem is not that
version numbers are not linear, but that the history itself is not.

Of course, if you've used SVN extensively, you've been trained to think
that history has to be somewhat linear, and perhaps even that the trunk
branch is the only one needing QA attention. Migration from SVN to Git
is hard because you have to change the mental model, not just command
names and how revisions are named.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/