On Thu, Sep 5, 2013 at 11:52 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >> Now the pack index v3 probably needs to be improved a little, again to >> accommodate completion of thin packs. Given that the main SHA1 table is >> now in the main pack file, it should be possible to still carry a small >> SHA1 table in the index file that corresponds to the appended objects >> only. This means that a SHA1 search will have to first use the main SHA1 >> table in the pack file as it is done now, and if not found then use the >> SHA1 table in the index file if it exists. And of course >> nth_packed_object_sha1() will have to be adjusted accordingly. > > 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. One minor detail to sort out: the size of sha-1 table. Previously it's the number of objects in the pack. Now it's not true because the table may have more entries. So how should we record the table size? We could use null sha-1 as the end of table marker. Or we could make pack-objects to write nr_objects as the number of entries _after_ pack completion, not the true number of objects in thin pack. I like the latter (no more rehashing the entire pack after completion) but then we need a cue to know that we have reached the end of the pack.. -- Duy -- 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