Undo a git rerere resolution that was done in a rebase

Question

Okay, so I really like the git rerere command, although I haven't really used it that much other than letting it auto-magically record my conflicts and resolve them for me. However, I did mess up one of my conflict resolutions during quite a large rebase (rebasing a really stale feature branch with the latest release).

feature -> a - b - c - d

release -> e - f - g - h

rebase/feature -> e - f - g - h .
                                 ` a' - b' - c' - d'

So, say for instance that b' has an incorrect merge (thanks to me!), and I want to re-record that. How would I do it? I've seen the git checkout --conflict option, mentioned in Rerere Your Boat, but I'm not too clear on how that works and if it applies here. Maybe I have to checkout the merge conflict state and run git rerere once I correctly resolve this conflict?

Normally, I would just commit to the tip of the rebase branch, but it is a throw away. I'm just trying to handle conflicts ahead of time, so that when I sync up with that feature team, we minimize the time it takes. Make sense?

Solution

To simply remove all previous rerere resolutions, run rm -rf .git/rr-cache to remove the cache.

For a specific merge, you can tell rerere to forget the recorded resolution by re-executing the merge and allowing rerere to apply its recorded resolution in the work tree.

You can check out a' and then do a git merge b to get back into that situation (you'll probably be in a checkout of a detached head since you specified the commit hash of a', so be aware that you're not on a branch).

Then use git rerere forget FILE-WITH-BAD-MERGE where to specify the file whose recorded conflict resolution should be forgetten.

forget <pathspec>
Reset the conflict resolutions which rerere has recorded for the current conflict in .

(From the Git documentation for git-rerere.)

Comments

[tomekwi]

Whoever wants to forget all git rerere resolutions, the comment by @JánSáreník under stackoverflow.com/a/21635422/2816199 can be of tremendous help.

[Ján Sáreník]

You can also do rm -rf .git/rr-cache to clean rr cache completely.

[Dennis]

^^ this helped while rerere forget did not do it for me

[Bluu]

The original author was confused by git checkout --conflict. However, if you're in the middle of the rebase and don't want to start over, that option is on the right track. There is a more familiar option, -m. You can do git checkout -m FILE-WITH-BAD-MERGE to restore the file's more familiar, default conflict markers. As if you didn't have rerere's resolution applied in the first place.

[imz -- Ivan Zakharyaschev]

git checkout -m and --conflict does not always produce a file with conflict markers (as I've just seen): if it succeeds merging the two variants, it shows no conflicts, although the result may be unwanted (from your point of view). Not sure whether git rerere records anything at all for such files, so you might not need to forget anything, because the unwanted results comes from another mechanism.

[solstice333]

is git rerere forget <pathspec> meant to be used within or outside merge context? I'm getting a no-op outside of merge context and an "error: no remembered resolution for <pathspec>" within merge context. I'm positive there is a remembered resolution for it, b.c. at the start of the merge, it applied recorded resolutions.

[gitaarik]

It works a bit confusing, because you first have to do the merge, and the (bad) recorded pre-image will be applied. THEN you have to do remove the recorded pre-image with git rerere forget <file>. Then you should git reset --hard origin/<branch> to again do the merge from there, and only then you get the original conflict again and you can correct the resolve.