Nicolas Pitre <nico@xxxxxxx> writes: > Support for large packs exceeding 31 bits in size won't impose an index > size bloat for packs within that range that don't need a 64-bit offset. > And because newer objects which are likely to be the most frequently used > are located at the beginning of the pack, they won't pay the 64-bit offset > lookup at run time either even if the pack is large. > > Right now an index version 2 is created only when the biggest offset in a > pack reaches 31 bits. It might be a good idea to always use index version > 2 eventually to benefit from the CRC32 it contains when reusing pack data > while repacking. > ... > @@ -582,6 +602,18 @@ static void write_index_file(void) > struct object_entry **list = sorted_by_sha; > struct object_entry **last = list + nr_result; > uint32_t array[256]; > + uint32_t index_version; > + > + /* if last object's offset is >= 2^31 we should use index V2 */ > + index_version = (objects[nr_result-1].offset >> 31) ? 2 : 1; Although write_pack_file() iterates objects[] array in the ascending order of index and calls write_one() for each of them, in the presense of "we write base object before delta" rule, is it always true that the last object in the objects[] array has the largest offset? - 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