On Wed, Nov 02, 2011 at 09:19:03PM -0700, Shawn Pearce wrote: > > [...] But they can use sendfile() on the server they have and get > a lot of improvement in clone speed due to lower system load, > plus resumable clone for the relatively stable history part. Setting aside the system load issue for now, couldn't we simply do the following? 1. Figure out HAVE's and WANT's [1], based on which an ad-hoc pack will be made and sent to the client. 2. Cache the information on disk (not the pack but the information to re-create it), and give the client a 'ticket number' which corresponds to that ad-hoc pack. 3. Start downloading the packfile When the connection drops, we can resume like this: 1. Send the previously received 'ticket number', and the amount of previously received data. 2. Re-generate the pack from the HAVE's and WANT's cached under 'ticket number'. (This may fail if the repo state has changed such that previously accessible refs are now inaccessible.) 3. Resume download of that pack. The upside of this approach is that it would work automatically, without any manual setup by the server admin. All the previously discussed ideas skip the step where we figure out the HAVE's and WANT's. And to me that implies that we manually prepare a packfile somewhere on disk, which contains what the user usually WANT's and is allowed to have (think per-branch access control). Even if we disregard access control, wouldn't that at least require the server to create a "clean" pack which does not contain any objects from the reflog? The whole mirror thing could be pursued independently of the resume capability, and if each git repo is capable of resuming the mirrors can be plain git clones as well. Just my 2 cents, Clemens -- 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