[Summary] Issue occurs when two branches reorder lines of the same file and are then merged back to the base branch. Instead of getting a content merge conflict, the branches are merged successfully and a line in the file is duplicated. [Steps to Reproduce] 1. initialize a new repository and create a file with three lines of content: ``` a b c ``` and commit the result 2. branch from this commit and modify the contents of the file to be: ``` b a c ``` and commit the results 3. checkout master at commit from step one 4. branch from this commit and modify the contents of the file to be: ``` b c a ``` and commit the results 5. checkout master at the commit from step one 6. merge the first branch (results in ff-merge) 7. merge the second branch (results in auto merge_3way) 8. examine file contents: ``` b a c a ``` [Expected Behavior] I expected to get a content merge conflict when attempting to merge the second branch. If the example is changed to be a file starting ``` a b c d ``` with two branches that change it to ``` c a b d ``` and ``` c d a b ``` respectively, and then the same sequence of merges, this is detected as a merge conflict as I would expect the single line case to be. [What Happened Instead] Instead merge succeeds without conflict and results in duplication of a line in the file [System Info] git version: git version 2.34.0.rc0.377.g6d82a21a3b cpu: x86_64 built from commit: 6d82a21a3b699caf378cb0f89b6b0e803fc58480 sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64 compiler info: clang: 13.0.0 (clang-1300.0.29.3) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh [Enabled Hooks] [Other Details] I tried this experiment with a few different merge strategies and got the same result regardless of which I picked. I did some rudimentary debugging and tracked handling of the merge for this file through merge-ort.c -> merge_3way -> ll_merge -> xdiff/xmerge.c -- It seems xdiff/xmerge is responsible for attempting the actual merge, deciding if there are conflicts and dropping the usual markers, or successfully auto-merging the changes. Wasn't sure of the testing process for xdiff and figured I would put this to the mailing list for feedback.
