Elijah Newren <newren@xxxxxxxxx> writes: > When using merge.conflictstyle=diff3 to have the "base version" be shown > in conflicts, there is the possibility that the base version itself has > conflicts in it. This comes about when there are more than one merge > base, and the merging of those merge bases produces a conflict. > Since this process applies recursively, it is possible to have conflict > markers nested at an arbitrary depth; to be able to differentiate the > conflict markers from different nestings, we make them all of different > lengths. I know it is possible that the common ancestor part that is enclosed by the outermost makers can have arbitrary conflicts, and they can be even recursive conflicts. But I fail to see why it is a problem. Perhaps that is because I am not particularly good at resolving merge conflicts, but as long as the common part of the outermost merge is identifyable, would that really matter? What I would do while looking at common ancestor part with conflicts (not even a recursive one) is just to ignore it, so... Not that I strongly oppose to incrementing the marker length at every level. I do not think it would hurt, but I just do not see how it would help.