Re: Mozilla .git tree

Junio C Hamano [off-list ref] wrote:

So I am inclined to chuck the previous patch that records the
next object number in each entry.  We could keep the 64-bit
offset, which would make an entry to be 28-byte instead of
32-byte.

I can agree with that.  :-)

Repacking is infrequent compared to searching for an object.
Asking the repack code to determine object lengths (especially if it
is going to deflate the entry anyway to verify it) isn't that much of
a performance hit.  As you pointed out its already happening today.

Using a 28 byte index entry instead of a 32 byte index entry means
the Mozilla historical pack index will only be 52.4 MiB rather than
the slightly larger 59.9 MiB.  1.9x10^6 objects will do that to you.

-- 
Shawn.