Junio C Hamano <junkio@xxxxxxx> 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. - 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