Re: Git commit generation numbers

On 07/20/2011 08:18 PM, david@lang.hm wrote:

On Wed, 20 Jul 2011, Phil Hord wrote:

quoted

On 07/20/2011 07:36 PM, Nicolas Pitre wrote:

quoted

On Wed, 20 Jul 2011, david@lang.hm wrote:

quoted

If the generation number is part of the repository then it's going to
be the same for everyone.

The actual generation number will be, and has to be, the same for
everyone with the same repository content, regardless of the cache 
used.
It is a well defined number with no room to interpretation.

Nonsense.

Even if the generation number is well-defined and shared by all 
clients, the only quasi-essential definition is "for each A in 
ancestors_of(B), gen(A) < gen(B)".

In practice, the actual generation number *will be the same* for 
everyone with the same repository content, unless and until someone 
develops a different calculation method.  But there is no reason to 
require that the number *has to be* the same for everyone unless you 
expect (or require) everyone to share their gen-caches.

and I think this is why Linus is not happy with a cache. He is seeing 
this as something that has significantly more value if it is going to 
be consistant in a distributed manner than if it's just something 
calculated locally that can be different from other systems.

It will only be used locally, so it needn't be consistent with anyone 
else's.

if it's just locally generated, then I could easily see generation 
numbers being different on different people's ssstems, dependin on the 
order that they see commits (either locally generated or pulled from 
others)

If it's part of the commit, then as that commit gets propogated the 
generation number gets propogated as well, and every repository will 
agree on what the generation number is for any commit that's shared.

I agree that this consistancy guarantee seems to be valuable.

I can't see why.

quoted

Surely there will be a competent and efficient gen-cache API.  But 
most code can just ask if B --contains A or even just use rev-list 
and benefit from the increased speed of the answer.  Because most 
code doesn't really care about the gen numbers themselves, but only 
the speed of determining ancestry.

in that case, why bother with generation numbers at all? the improved 
data based heristic seems to solve that problem.

Does it?  Surely the ruckus would've died down in that case.  But I 
haven't been reading pu.

It seems to me that the main drawback to a gen-cache is that it slows 
down the first operation after even a local clone (with just hardlinks).

On the other hand, I see too many nails in the distributed-gen-numbers 
coffin:  legacy commits can't catch up (and therefore suffer), and 
legacy clients can trash or corrupt even "new-style" commits.

Phil