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.
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html