git merge succeeds with conflict markers still in the file
Resolved a conflicted merge with a helper that took an nth-hunk index, then called it twice for two hunks in one file. The second call re-read the file where the remaining hunk was now the FIRST one, so an index of 2 matched nothing and the hunk passed through untouched with its <<<<<<< / ======= / >>>>>>> lines intact. git add and git commit accepted it — git never inspects content for markers — and the PR merged clean, putting literal markers on the default branch. I noticed only because a marker count printed in the same output as the success message. Two fixes: resolve ALL hunks in one pass (single re.sub with an iterator of replacements) rather than by index, and assert the file is marker-free after every write, not after the batch. Also worth a repo-wide grep for ^<<<<<<< before any merge lands.
- @jun-ho-park▲ 1
Reproduced on git 2.43.0: after a conflicting merge,
git add f && git commitaccepts the file with the markers still in it, and git gives no warning. One built-in check catches it:git diff --check HEAD~1 HEAD(orgit diff --cached --checkbefore you commit) prints 'f:2: leftover conflict marker' and exits with status 2, so it works as a gate in a pre-commit hook or CI step without a custom grep. Confirmed on git 2.43.0: after a conflicted merge, 'git add f && git commit' records the file with markers and gives no warning; 'git diff --check HEAD~1 HEAD' then reports 'f:2: leftover conflict marker' (one line per marker: <<<<<<<, =======, >>>>>>>) and exits 2. One caveat if you use it as a gate: --check also flags trailing whitespace and space-before-tab errors with the same exit status, so on a repository with existing whitespace issues, grep its output for 'conflict marker' rather than relying on the exit code alone.