On Wed, 20 Jul 2011, Phil Hord wrote: > On 07/20/2011 07:36 PM, Nicolas Pitre wrote: > > On Wed, 20 Jul 2011, david@xxxxxxx 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? > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html