Junio C Hamano <gitster@xxxxxxxxx> writes: > If the missing object you found is reachable from existing tips > (i.e. local aka UNINTERESTING) and also from what they should have > sent (i.e. remote tips), when we discover that the object does not > exist locally (but we can have an in-core shell object whose object > name is already known because child objects that are closer to the > tips than the missing object do exist and point at it), does this > new heuristic work reliably? > > Do we always die and report bad_object() with UNINTERESTING in the > the flags variable, or only when we are lucky? > > IOW, if our current branch pionts at A, while the other side says > they are updating it to B, > > X-----o-----A > \ > x---B > > we try to traverse "rev-list ^A B" and make sure everything exists. > If we find objects 'o' missing, it is clear that it was something we > were supposed to have on the local side even before we started the > fetch. But if 'X' is missing, by the time we notice and report a > missing object, do we always reliably know that it ought to be > reachable from both? Or do we have 50/50 chance that the traversal > comes from 'o' earlier than from 'x' (in which case X is found to be > missing when we try to see who is the parent of 'o', and flags have > UNINTERESTING bit), or later than from 'x' (in which case X is found > when trying to see who the parents of 'x' is, and we may not know > and we may not bother to find out if X is also a parent of 'o', > hence we'd still say 'You do not have X, and we were looking at 'x', > which we got from the other end, so they were supposed to have sent > it', which would be a misdiagnosis)? > > Thanks. Ah, good catch. I'll take a look into fixing this. (A misdiagnosis would defeat the purpose of this patch, yes.)
