Nicolas Pitre [off-list ref] writes:
quoted hunk
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?