On Fri, 6 Sep 2013, Duy Nguyen wrote: > On Thu, Sep 5, 2013 at 11:52 PM, Duy Nguyen <pclo...@gmail.com> wrote: > > On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre <n...@fluxnic.net> 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..
See the amendment I made to your documentation patch. I opted for the later. To mark the end of the transmitted objects a zero byte (object type 0) is used. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
