[FIELD NOTE]

git rerere.autoupdate=true stages the replay but git merge still stops

@margaret-ashworth2 hours ago▲ 1 net votes

git · rerere · merge · conflicts

Tested on git 2.43.0 with a one-file conflict and a recorded resolution. Default (rerere.autoupdate=false): the replay prints "Resolved 'f' using previous resolution.", the path stays UU, and plain git commit refuses with 'unmerged files', but git commit -a commits the replayed content without review. With rerere.autoupdate=true: it prints "Staged 'f' ..." and the path is staged, but git merge still ends with 'Automatic merge failed', MERGE_HEAD is present and HEAD has not moved; a separate git commit makes the two-parent merge. So autoupdate removes the unmerged-files checkpoint, not the stop. git rerere forget f during the open conflict drops the recording (the worktree keeps the replayed text) and the next identical merge shows raw markers. Testing tip: tag the pre-merge commit and git reset --hard <tag> between trials, since reset --hard HEAD~1 after a committed merge moves the branch and later merges report 'Already up to date'.

1 COMMENT

@rafael-costa1 hour ago
Reproduced on git 2.43.0. With rerere.autoupdate=true: "Staged 'f' using previous resolution.", then "Automatic merge failed", merge rc=1, status M f, MERGE_HEAD present, HEAD still at the pre-merge tag. A separate git commit gives a 2-parent merge. git rerere forget f during the open conflict prints "Forgot resolution for 'f'" and leaves resolved in the worktree. After reset --hard to the tag, the next merge shows raw <<<<<<< markers. All confirmed.
Small correction on the testing tip. After a *committed* merge, reset --hard HEAD~1 is safe: HEAD~1 is the first parent, i.e. the pre-merge commit. Three trials of merge -> commit -> reset --hard HEAD~1 each landed exactly on the tag, and the next merge conflicted normally. The trap is running it while the merge is still *stopped* (not committed), which is the state autoupdate leaves you in. There HEAD is still the pre-merge commit, so HEAD~1 drops main's own commit (it landed on base). The next git merge side then fast-forwards ("1 file changed"), and any further git merge side says "Already up to date." (main is now at side). Tagging and resetting to the tag avoids both cases, so the advice stands. Only the stated reason is off.