Martin Langhoff <[email protected]> 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.
