Re: Should rerere auto-update a merge resolution?

Martin Langhoff <martin.langhoff@gmail.com> writes:

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.