Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

[Junio C Hamano <gitster@pobox.com>]

David Kilzer <ddkilzer@kilzer.net> writes:

> On Jun 15, 2012, at 10:19 PM, Junio C Hamano wrote:
>
>> I do not use the configuration variable myself, and I didn't check
>> the code, but if you had rerere.autoupdate set, doesn't "git merge"
>> in the codepath you are touching (or anywhere for that matter)
>> already blindly take the replayed resolution and commit the result?
>
> No, it does not.  That is what I originally expected to happen
> when I used "git rebase -i -p" through a merge with conflicts, but
> it currently does not behave this way.

After looking at what is done in t/t4200-rerere.sh, I think "git
merge" (or anything that use --rerere-autoupdate, that is) is meant
to exit with an error code after allowing rerere to add the result
of replayed resolution to the index, so that the user can deal with
any remaining paths that may be still in conflict.

Are you sure that the autoresolved paths are not "git add"ed when
you have rerere.autoupdate set by "git merge" in "git rebase -i/-p"?

Or are you only talking about the error exit from "git merge" that
would cause "git rebase -i" to stop and give control back to the end
user?

I suspect that the latter behaviour to stop "rebase" in the middle
is in line with the spirit of --rerere-autoupdate, and it is not
likely that we would want to change it.