Re: warning: no common commits - slow pull

Daniel Barkalow [off-list ref] 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.

On Thu, 28 Feb 2008, Junio C Hamano wrote:

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.

Absolutely; that was actually my first guess at why it was failing, and I 
think it's a necessary aspect to the failure. Let me see if I can get your 
test case to exhibit the problem for me and look into it further.

	-Daniel
*This .sig left intentionally blank*