Re: [PATCH v4 01/11] pack-objects: a bit of document about struct object_entry
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Mar 17, 2018, 11:59 UTC
- Message-ID
- <CACsJy8CVQBgs4s8VyQ2PoVx3kVv+n76ctwjCe_2YkLGiWd2r2A@mail.gmail.com>
- In-Reply-To
- <xmqqfu4z2232.fsf@gitster-ct.c.googlers.com>
On Fri, Mar 16, 2018 at 9:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
>> +/* >> + * basic object info >> + * ----------------- >> + * idx.oid is filled up before delta searching starts. idx.crc32 and >> + * is only valid after the object is written out and will be used for > > "and is"?
There was another field that I thought was only valid after blah blah. But it was wrong and I forgot to delete this "and" after deleting that field.
Show 5 quoted lines
>> + * "hash" contains a path name hash which is used for sorting the >> + * delta list and also during delta searching. Once prepare_pack() >> + * returns it's no longer needed. > > Hmm, that suggests an interesting optimization opportunity ;-)
Heh.. it does not reduce peak memory consumption though which is why I'm less interested in freeing it after prepare_pack().
Show 10 quoted lines
>> + * source pack info >> + * ---------------- >> + * The (in_pack, in_pack_offset, in_pack_header_size) tuple contains >> + * the location of the object in the source pack, with or without >> + * header. > > "with or without", meaning...? An object in the source pack may or > may not have any in_pack_header, in which case in_pack_header_size > is zero, or something? Not suggesting to rephrase (at least not > yet), but trying to understand.
The location with the header (i.e. true beginning an object in a pack) or without/after the header so you are at the zlib stream, ready to inflate or reuse. I'll rephrase this a bit.
Show 7 quoted lines
>> + * >> + * delta_child and delta_sibling are last needed in >> + * compute_write_order(). "delta" and "delta_size" must remain valid >> + * at object writing phase in case the delta is not cached. > > True. I thought child and sibling are only needed during write > order computing, so there may be an optimization opportunity there.
See. I wrote all this for a reason. Somebody looking for low hang fruit can always find some ;-)
-- Duy