On Thu, Nov 10, 2011 at 3:43 PM, Jeff King <peff@xxxxxxxx> wrote: > One possible option for resumable clones that has been discussed is > letting the server point the client by http to a static bundle > containing most of history, followed by a fetch from the actual git repo > (which should be much cheaper now that we have all of the bundled > history). This series implements "step 0" of this plan: just letting > bundles be fetched across the network in the first place. > > Shawn raised some issues about using bundles for this (as opposed to > accessing the packfiles themselves); specifically, this raises the I/O > footprint of a repository that has to serve both the bundled version of > the pack and the regular packfile. > > So it may be that we don't follow this plan all the way through. > However, even if we don't, fetching bundles over http is still a useful > thing to be able to do. Which makes this first step worth doing either > way. Jeff, this is a great series, I think the cleanups and refactors should get integrated independently of the bundle-cloning stuff. One thing I'm not comfortable with is the "flexibility" allowed in bundle fetching - servers are allowed to send bundles if they see fit, and we have to detect it when they do (if I'm reading the "surprised" scenario in patch 9 correctly). Perhaps we can expose bundle fetching through /objects/info/bundles? It could possibly contain information about what bundles are available and what revs they contain. If bundles are found, fetch them; otherwise, go through the usual ref advertisement and other steps of the pack protocol. That way, we take out the "surprise" factor in the fetching protocol. -- Cheers, Ray Chuan -- 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