On Thu, Jan 21, 2010 at 09:42:36AM -0800, Junio C Hamano wrote: > "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. I thought about this some more: it seems that nothing in pack-protocol.txt dictates that client has to send have lines in order. The whole logic would be on client side. So a new capability will be there just in case we find a use for a server-side optimization later on, we don't need the client to behave differently in any way when this capability is enabled/disabled. Right? -- MST -- 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