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?
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.