Junio C Hamano <gitster@xxxxxxxxx> writes:
> Hmm, my knee-jerk reaction was that something may be keying off of the
> conflict ids to keep track of which ones are dealt with and which ones are
> yet to be resolved, but I don't recall any part of the implementation that
> would do something like that offhand. Sorry.
Heh, what was I thinking. Yes, rr-cache/ database keys off of the
conflict id, so if your repository has more than one contents that produce
exactly the same conflict, say F and G, then, most likely:
* You see one of them first, say F, record preimage.F and record its
resolution as postimage.F
* You encounter conflict G; record it in thisimage, try three-way merge
between postimage.F and that using preimage.F as the common ancestor.
If this doesn't work (and it likely doesn't), rerere punts.
Note that this issue can happen even when the trees you are currently
merging have only content derived from G and nothing related to F, as
their resolutions share the same conflict id.
I vaguely recall discussing this with you here and bringing up a possibile
solution for a situation like this; keep sets of <preimage, postimage>
(starting from the current {pre,post}image adding {pre,post}image.1,
{pre,post}image.2 and so on). When we see a new conflict (after a mergy
operation before "rerere" resolves it), try to run the three-way merge
with it and each pair, and if we don't find anything that successfully
merges, record it as a new half of the pre-post pair, incrementing the
counter, and record a new resolution to complete the new pair for later
use.
We also need to split "thisimage" into multiple ones in case this happens
in a single tree (i.e. contents derived from F and from G are both present
and produce the conflict in the same merge).
--
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