Nicolas Pitre <nico@cam.org> writes:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html