Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Thu, Feb 11, 2016 at 4:01 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> .... >> >> I really like this design. I'm tempted to implement it (since it >> lacks a bunch of the downsides of clone.bundle). > > A bit disappointed we still do not address resumable fetch. As you already said, the initial "clone" and subsequent incremental "fetch" are orthogonal issues. Because the proposed update to "clone" has much larger payoff than the proposed change to "fetch", i.e. * The amount of data that gets transferred is much larger, hence the chance of network timing out in a poor network environment is much higher, need for resuming much larger. * Not only the approach makes "clone" resumable and helping clients, it helps the server offload bulk transfer out to CDN. and it has much smaller damage to the existing code, i.e. * We do not have to pessimize the packing process, only to discard the bulk of bytes that were generated, like the proposed approach for "fetch". * The area new code is needed is well isolated and the switch to new protocol happens very early in the exchange without sharing code to existing codepath; these properties make it less risky to introduce regression. it is simply a good taste to give "clone" higher priority between the two. So I do not think there is much reason to feel disappointed. -- 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