On Thu, Nov 28, 2013 at 4:29 PM, Jeff King <peff@xxxxxxxx> wrote: >> - stablize pack order so we can resume downloading a pack > > I think stabilizing in all cases (e.g., including ones where the content > has changed) is hard, but I wonder if it would be enough to handle the > easy cases, where nothing has changed. If the server does not use > multiple threads for delta computation, it should generate the same pack > from the same on-disk deterministically. We just need a way for the > client to indicate that it has the same partial pack. > > I'm thinking that the server would report some opaque hash representing > the current pack. The client would record that, along with the number of > pack bytes it received. If the transfer is interrupted, the client comes > back with the hash/bytes pair. The server starts to generate the pack, > checks whether the hash matches, and if so, says "here is the same pack, > resuming at byte X". > > What would need to go into such a hash? It would need to represent the > exact bytes that will go into the pack, but without actually generating > those bytes. Perhaps a sha1 over the sequence of <object sha1, type, > base (if applicable), length> for each object would be enough. We should > know that after calling compute_write_order. If the client has a match, > we should be able to skip ahead to the correct byte. Exactly. The hash would include the list of sha-1 and object source, the git version (so changes in code or default values are covered), the list of config keys/values that may impact pack generation algorithm (like window size..), .git/shallow, refs/replace, .git/graft, all or most of command line options. If we audit the code carefully I think we can cover all input that influences pack generation. From then on it's just a matter of protocol extension. It also opens an opportunity for optional server side caching, just save the pack and associate it with the hash. Next time the client asks to resume, the server has everything ready. -- 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