Re: git fetch -v not at all verbose?

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jan 21, 2010 at 09:42:36AM -0800, Junio C Hamano wrote:
> "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.

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