From: Jeff King <peff@peff.net>
Date: Wed, 30 Jan 2013 07:12:09 GMT
Subject: Re: [PATCH 4/6] introduce a commit metapack
Message-ID: <20130130071209.GD11147@sigill.intra.peff.net>
In-Reply-To: <7vtxpzq2uv.fsf@alter.siamese.dyndns.org>

On Tue, Jan 29, 2013 at 10:08:08AM -0800, Junio C Hamano wrote:

> > In order to reduce the disk footprint and I/O cost, the future
> > direction for this mechanism may want to point into an existing
> > store of SHA-1 hashes with a shorter file offset, and the .idx file
> > could be such a store, and in order to move in that direction, you
> > cannot avoid tying a metapack to a pack.
> 
> Have you considered if we can extend the .idx format version 2
> without actually having to bump the version number?  My quick
> reading of check_packed_git_idx() tells me that we have a gap after
> the "large offset table" that we can place extensions, but I may be
> mistaken.  If we indeed can, then perhaps adding a series of
> 
> 	4-byte "id" header
>         4-byte extension length (or 8-byte)
>         ... N-byte worth of extension data ...
> 
> followed by
> 
> 	20-byte SHA-1 checksum of all the extension sections
> 	8-byte file offset to the first extension section

I considered it, but didn't look into it closely. My feeling was that it
added extra complexity, without adding any real advantage that a
separate file would not.

>From this:

> Then it will be very natural for the extension data that store the
> commit metainfo to name objects in the pack the .idx file describes
> by the offset in the SHA-1 table.

I guess your argument is that putting it all in the same file makes it
more natural for there to be a data dependency.

> As we always say, .idx is a local cache and bumping its version is
> not a huge headache compared to other longer term storage items.

True, but it is even less headache if the file is totally separate and
optional.

-Peff