Junio C Hamano <gitster@xxxxxxxxx> writes: > An interesting thing is that c32ca691c2^2 that moved the assignment > to this big red switch variable around causes 3-way merge to fail in > a miserable way. The "moving around" would involve removing from > the same location as the rebased patch below removes, plus adding > the assignment elsewhere, so "both sides removed the assignment from > this hunk, so take that" would correctly leave the original assignment > we see in the second hunk above removed, but fails to notice that > the assignment made elsewhere (the result of "moving around" patch) > is no longer needed, because "c32ca691c2^2 added one and this change > does not do anything there, so take the addition" cleanly resolves > to an incorrect merge result. Total tangent. One frustrating thing is that we do this a bit better at the tree level merge. After read-tree does three-way merge at the tree level, what is passed to the merge-recursive machinery has "side A added" and "side A removed" left unresolved, so that the post-processing phase could try to match them up and say "aha, side A moved that path elsewhere while side B just removed, which is a conflict". I wish if xdiff/xmerge.c could learn a similar trick, but the necessary change feels quite involved, error prone and too magical.
