On Thu, Jul 14, 2011 at 11:55:39AM -0700, Linus Torvalds wrote: > 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 -- 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