Martin Langhoff <martin.langhoff@xxxxxxxxx> writes: > - when I tell it to forget, won't it forget the pre-resolution state? I do not recall the details of what I did ;-) so I played around a bit. Here is what I did: git checkout master^0 git merge --no-ff --no-edit pb/trailers-from-command-line git merge --no-ff --no-edit jk/trailers-parse I know that the last one I know gets conflict and triggers rerere to replay the recorded resolution. Imagine that I earlier botched resolution and the working tree contents is wrong or something at this point. make test ;# fails, perhaps So I can do: git rerere forget <path> After git rerere forget, I observe (check subdirectories in .git/rr-cache/ whose timestamps are recent) that postimage gets removed but preimage and thisimage stay. I can then edit that file, and say "git rerere" again, which is greeted by "Recorded resolution for '<path>'". I do not recall if I designed it that way or not, but it even seems to work correctly if you had "git add -u" after the botched auto application (i.e. between the "make test" step and "rerere forget" step in the above sequence). I never do "add -u" myself before testing so I didn't notice. If you want to _see_ the conflicts again while fixing a botched resolution, then you'd need to do a bit more involved recovery. After seeing "make test" fail and realize your older resolution is botched, you'd probably do: git checkout -m <path> to unmerge, "rerere forget <path>", fix the botched resolution and then finally "rerere" to record the correction.
