Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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. -- 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
