Re: warning: no common commits - slow pull

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

Daniel Barkalow <barkalow@iabervon.org> writes:

> Actually, I just realized something which should have been obvious: when 
> we reconnect, we get a list of the remote's refs, which we currently 
> discard immediately. We should actually pass this list to fetch_pack() if 
> we just reconnected, so that the client side always does the interaction 
> with the right idea of the server's refs, and discard it afterwards. The 
> fact that the user of transport_*() doesn't find out that the server 
> side's refs change in the middle of the life cycle and can't find out in 
> any way doesn't matter too much, so long as each actual connection is 
> internally consistant. (And the situation is no different from how it used 
> to be with git-fetch.sh: if you get a different mirror later, you may 
> discover that the server now doesn't have refs that it seemed to 
> advertize, but nothing weird happens.)

I think that would also be a valid way to solve this "stale idea
of what the other side has" and can replace my weatherbaloon
patch.

Another potential problem area is if find_common() does the
right thing when it is called for the second time.  I did not
check if you clear COMMON, SEEN, COMPLETE etc. bits from the
object database before initiating the second round, but if you
didn't, I am afraid these bits left over from the primary
transfer might interfere the common ancestor discovery during
the second round.