"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: >> > Are you fetching from a configured remote that has tracking branches, >> > or are you fetching through a one-shot URL pasted onto the command >> > line? >> >> Configured remote. > > Hmm. I wonder if we should try to shortcut the commit walking in > a case like this and just feed the tracking branches we already have. You mean that the main culprit is the presense of thousdands of commits that fetcher has obtained through the other remotes (and his own) that the uploader makes fetcher walk all the way, in the false hope that there might be a commit among them that is closer to the commits being fetched than the ones at the tip of tracking branch the fetcher has for this uploader currently? And the solution might be to tell only about the tips of remote tracking branches fetcher has obtained from this particular uploader, not about other remote tracking bracnesh it got from others or his own local branches (which may have merged from other remotes)? It is a clever idea but I suspect it may not work well in practice. For example, suppose a project is two-tier, say, with top-level and subsystem repositories, the former of which regularly merge from the latter, and you are a participant primarily working on the subsystem. You fetch daily from the subsystem repository, but weekly from the top-level. Now, when you fetch from the top-level, the remote tracking refs you have for it are much more stale than your other refs. The top-level would have acquired a lot more commits from the same subsystem repository since you fetched from there the last time, and you already have many of them through your daily fetch from the subsystem repository. To minimize the transfer in such a case, the fetcher does want to tell the uploader that it has those commits from the same subsystem repository, so that the commit walker can stop at a recent merge into the top-level from the subsystem repository. There was a discussion about updating the commit walk exchange to bisect the history (skip and try a much older one to see if it is reachable, but to avoid overshooting, step back and see if a newer one is still common). It would be a lot more work and needs to be implemented as a new protocol capability, but I think it is the right way to go in the longer term. -- 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