On Thu, 5 Sep 2013, Nicolas Pitre wrote: > If the path or name index is zero, this means the entry data is to be > found inline rather than being located in the dictionary table. This is > there to allow easy completion of thin packs without having to add new > table entries which would have required a full rewrite of the pack data. > > Signed-off-by: Nicolas Pitre <nico@xxxxxxxxxxx> I'm now dropping this patch. Please also remove this from your documentation patch. I think that we've found a way to better support thin packs. You said: > What if the sender prepares the sha-1 table to contain missing objects > in advance? The sender should know what base objects are missing. Then > we only need to append objects at the receiving end and verify that > all new objects are also present in the sha-1 table. So the SHA1 table is covered. Missing objects in a thin pack cannot themselves be deltas. We had their undeltified form at the end of a pack for the pack to be complete. Therefore those missing objects serve only as base objects for other deltas. Although this is possible to have deltified commit objects in pack v2, I don't think this happens very often. There is no deltified commit objects in pack v4. Blob objects are the same in pack v2 and pack v4. No dictionary references are needed. That leaves only tree objects. And because we've also discussed the need to have non transcoded object representations for those odd cases such as zero padded file modes, we might as well simply use that for the appended tree objects already needed to complete a thin pack. At least the strings in tree entries will be compressed that way. Problem solved, and one less special case in the code. What do you think? Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html