Re: [PATCH 06/10] pack-objects: learn about pack index version 2
- From
Junio C Hamano <junkio@cox.net>
- Date
- Apr 9, 2007, 05:32 UTC
- Message-ID
- <7vabxi6rkv.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <11760952002410-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> writes:
Show 19 quoted lines
> 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?