On Fri, Nov 4, 2011 at 02:35, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Am 11/4/2011 9:56, schrieb Clemens Buchacher: >> Cache ... not the pack but the information >> to re-create it... > > It has been discussed. It doesn't work. Because with threaded pack > generation, the resulting pack is not deterministic. The information to create a pack for a repository with 2M objects (e.g. Linux kernel tree) is *at least* 152M of data. This is just a first order approximation of what it takes to write out the 2M SHA-1s, along with say a 4 byte length so you can find given an offset provided by the client roughly where to resumse in the object stream. This is like 25% of the pack size itself. Ouch. This data is still insufficient to resume from. A correct solution would allow you to resume in the middle of an object, which means we also need to store some sort of indicator of which representation was chosen from an existing pack file for object reuse. Which adds more data to the stream. And then there is the not so simple problem of how to resume in the middle of an object that was being recompressed on the fly, such as a large loose object. By the time you get done with all of that, your "ticket" might as well be the name of a pack file. And your "resume information" is just a pack file itself. Which would be very expensive to recreate. -- 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