Re: Git commit generation numbers
- From
Nicolas Pitre <nico@fluxnic.net>
- Date
- Jul 21, 2011, 00:58 UTC
- Message-ID
- <alpine.LFD.2.00.1107202041480.21187@xanadu.home>
- In-Reply-To
- <4E276DF8.8030301@cisco.com>
On Wed, 20 Jul 2011, Phil Hord wrote:
Show 14 quoted lines
> On 07/20/2011 07:36 PM, Nicolas Pitre wrote: > > On Wed, 20 Jul 2011, david@lang.hm wrote: > > > > > 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?
Show 5 quoted lines
> 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.
Nicolas