Re: Git commit generation numbers

From: Jeff King <peff@peff.net>
Date: Jul 14, 2011, 20:07 UTC
Message-ID: <20110714200717.GF26918@sigill.intra.peff.net>
In-Reply-To: <CA+55aFzuQnfo1iywnp-WAajMHe2+6_HOM85aw0bS+p0xv5RyhA@mail.gmail.com>

On Thu, Jul 14, 2011 at 12:51:39PM -0700, Linus Torvalds wrote:

Show 10 quoted lines

> On Thu, Jul 14, 2011 at 12:46 PM, Ted Ts'o <tytso@mit.edu> wrote:
> >
> > Would it be considered evil if we put the generation number in the
> > pack, but not consider it part of the formal object (i.e., it would be
> > just a cache, but one that wouldn't change once the pack was created)?
> 
> That would actually be a major change to data structures, and would
> require some serious surgery and be hard to support in a
> backwards-compatible way (think different git versions accessing the
> same repository).

If we put it in the index, but not the pack, then it wouldn't be any more painful than pack index v2. I don't recall there being huge fallout from that; we just gave a reasonable deprecation period before switching it on as the default.

I'm not sure it is much less crappy than having the cache in a separate file. It does take less space, since the pack index already contains all of the sha1s. But if we don't like the on-the-fly writing of what was in my series, it would not be hard to generate the same cache during pack-index time. Not having it in a separate file makes it hard to invalidate the cache when the graph changes (due to grafts or replace refs). But maybe we don't care about that. Or maybe it's OK to tell the user to manually rebuild the pack index if they tweak those features.

-Peff