Do I have to commit a merge to make git-rerere record my conflict resolution?

Question

I'm using git-rerere for its intended purpose, to record conflict resolutions between two branches (master and a topic branch) incrementally as those branches develop, without creating unnecessary merge commits. However, even after reading the git-rerere manpage I'm a little unclear on when rerere actually records my conflict resolution. My standard workflow for detecting and resolving new merge conflicts is to do git merge master from the topic branch, resolve the conflicts, then stage all the files and commit the merge with git commit -m "Finished test merge", and then undo the merge using git reset --hard HEAD^, leaving behind only the recorded resolutions stored by git-rerere.

However, this seems a bit silly. Creating a commit and then undoing it just to record the resolution? After reading the manpage for git-rerere, I'm still not really clear on when it records my resolutions. Is it sufficient to just stage the conflicted files or do I actually need to create the merge commit after resolving the conflicts, like I've been doing?

Answer 1

From the manpage:

Running the git rerere command immediately after a conflicted automerge
records the conflicted working tree files, with the usual conflict
markers <<<<<<<, =======, and >>>>>>> in them. Later, after you are
done resolving the conflicts, running git rerere again will record the
resolved state of these files.

And:

As a convenience measure, git merge automatically invokes git rerere
upon exiting with a failed automerge and git rerere records the hand
resolve when it is a new conflict, or reuses the earlier hand resolve
when it is not. git commit also invokes git rerere when committing a
merge result. What this means is that you do not have to do anything
special yourself (besides enabling the rerere.enabled config variable).

So you don't have to commit and undo the commit. You can just run git rerere without parameters to record the commit.

Answer 2

Is it sufficient to just stage the conflicted files

You must be sure to resolve the conflict without leaving conflict markers.

See commit f427869, commit bc4caec (28 Aug 2018) by Thomas Gummerer (tgummerer).
Suggested-by: Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit d88949d, 17 Sep 2018)}

See commit b9b07ef (28 Aug 2018) by Thomas Gummerer (tgummerer).
Helped-by: Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 4dd0c4a, 17 Sep 2018)}

.gitattributes: add conflict-marker-size for relevant files

Some files in git.git contain lines that look like conflict markers, either in examples or tests, or in the case of Documentation/gitk.txt because of the asciidoc heading.

Having conflict markers the same length as the actual content can be confusing for humans, and is impossible to handle for tools like 'git rerere'.

Work around that by setting the 'conflict-marker-size' attribute for those files to 32, which makes the conflict markers unambiguous.