> The current protocol has the following problems that limit > us: > > - It is not easy to make it resumable, because we > recompute every time. This is especially problematic for > the initial fetch aka "clone" as we will be talking about > a large transfer. Redirection to a bundle hosted on CDN > might be something we could do transparently. > > - The protocol extension has a fairly low length limit. > > - Because the protocol exchange starts by the server side > advertising all its refs, even when the fetcher is > interested in a single ref, the initial overhead is > nontrivial, especially when you are doing a small > incremental update. The worst case is an auto-builder > that polls every five minutes, even when there is no new > commits to be fetched.
A lot of focus about the problems with ref advertisement is about the obvious problem mentioned above (a bad problem indeed). I would like to add that there is another related problem that all potential solutions to the above problem do not neccessarily improve. When polling regularly there is also no current efficient way to check on the current state of all refs. It would be nice to also be able to get an incremental update on large refs spaces. Thanks, -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
