Re: Git commit generation numbers
- From
Jeff King <peff@peff.net>
- Date
- Jul 14, 2011, 19:12 UTC
- Message-ID
- <20110714191252.GB26918@sigill.intra.peff.net>
- In-Reply-To
- <CA+55aFzvib7QF-J3fBj2brcQifXGqoeK1t7vfx6pcJmJAEO0dw@mail.gmail.com>
On Thu, Jul 14, 2011 at 11:55:39AM -0700, Linus Torvalds wrote:
Show 5 quoted lines
> I'm actually much more nervous about a cache being inconsistent than I > would be about having generation numbers in the tree. The latter we > can (and should - but my patch didn't) add a fsck test for, and then > you would never get into some situation where there's some really > subtle issue with merge base calculation due to a corrupt cache.
Interesting. I'm nervous about that, too, which is why I _favor_ the cache. Because we calculate the cache ourselves, we know its accurate according to the parent pointers. If we find a bug, we fix it and bump the cache version, which forces it to regenerate.
Contrast that with a bogus generation number that makes its way into an actual commit object. That's there for eternity, just like the commit timestamp skew we already have. I find it much less likely to happen than skew in the commit timestamp, if only because generations are a dirt-simple concept. But it is a case where there is duplicated information in the actual DAG, and if that information doesn't match up we are screwed.
-Peff