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 -- 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