Re: git fetch -v not at all verbose?

[Junio C Hamano <gitster@pobox.com>]

"Shawn O. Pearce" <spearce@spearce.org> 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.