Philip Oakley <philipoakley@iee.email> writes: > I believe this happens when no merge-base is found between the two > lines of development that are being merged, so a fake merge-base is > created to allow the regular 3-way merge to occur. s/no merge-base is/more than one merge-base are/; then a synthetic merge base is computed in order to perform the merge the end-user requested first, and the computation of that synthetic merge base may involve merge conflicts. After that, the merge logic pretends that the two versions being merged both derived from such a common ancestor version _with_ conflict markers in it, and may conflict with each other around that existing (inner) conflict markers to leave a rather messy result. It is particularly bad when both branches did the same thing only on one side the inner merge conflicted but not on the other side---one side of inner conflict marker (say "<<<<<<<<") may disappear when the merged branches made the same change (so "both side changed identically, resolve to their same result" 3-way merge rule would apply) and around that area the result will not have the conflict marker from the inner merge, and the other side will say "one side made into this shape, the other side made into that shape, from this common ancestor version" in the diff3 format, which would mean that we would see conflict marker lines from the inner merge between "|||||" and "=====" lines in the outer merge (i.e. the common ancestor version). The conflict markers of the inner merge are longer than those of the outermost merge, so you could sift them by careful eyeballing, but it is rather hard to read.
