Re: Git commit generation numbers

On 07/20/2011 08:58 PM, Nicolas Pitre 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)".

Sure.  But what do you gain by making holes in the sequence?

Depends on the algorithm.  Probably speed.  Possibly more efficient 
limited-cache building (jit-style discovery in reverse, as-needed, for 
example).

What do you gain by enforcing contiguousness?  Why not require all gen 
numbers to be even?  Or prime?  ;)

quoted

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 with the above you clearly reinforced the argument _against_ storing
the generation number in the commit object.  If you can imagine a
different calculation method already, and if it is actually useful, then
who knows if something even better could be done eventually.

Good.  Nice to see I'm being self-consistent, then.

Phil