On Fri, Mar 16, 2018 at 9:32 PM, Junio C Hamano <gits...@pobox.com> wrote: >> +/* >> + * 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. >> + * "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(). >> + * 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. >> + * >> + * 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
