Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
+ Johannes Schindelin [sorry, should have added you at the beginning of the thread]
On Jun 16, 2012, at 10:49 PM, Junio C Hamano wrote:
Show 21 quoted lines
> 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"?
You are correct, autoresolved paths are "git add"ed when rerere.autoupdate is true.
Argh...in my original patch, I wasn't setting rerere.autoupdate. After fixing that in the test, it's clear that the patch is no longer needed.
Show 7 quoted lines
> 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.
If it could be guaranteed that all changes in a merge commit would be preserved when running "git rebase -i -p" with rerere.autoupdate enabled, I think that would be an argument for not returning control to the user during the rebase operation. However, changes to non-conflicted files in a merge commit are currently lost in this case, so it would be too dangerous to enable this behavior now.
Dave
David Kilzer <ddkilzer@kilzer.net>