Re: [PATCH] rebase: Allow merge strategies to be used when rebasing

[Junio C Hamano <junkio@cox.net>]

Eric Wong <normalperson@yhbt.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>>
>> >> 	git-merge-$strategy $cmt^ -- HEAD $cmt
>> >
>> > Changing the 'git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt"'
>> > line in call_merge() to this seems to have broken more tests.
>> 
>> Oh, that is to be expected if you changed git-merge -s recursive
>> with git-merge-recursive without other changes.  The former
>> makes a commit (which your original patch later used to create a
>> separate commit chain and discarded); the latter does not make a
>> commit but expects the caller to create a commit out of the
>> resulting index file.
>
> Oops, *smacks head*

Well, but you used it to do the right thing after all ;-).
The patch looks quite good.

>> I was originally hoping that rebasing would just be a matter of
>> listing sequence of commits to be ported onto a new base and
>> running "git-cherry-pick" on each of them in sequence.  Now
>> cherry-pick does not use merge machinery (hence does not use
>> git-merge-recursive), but if we change that then updating rebase
>> would be pretty much straightforward.  It just needs a UI layer
>> to guide the user through recovery process when the merge does
>> not resolve cleanly in the middle, no?
>
> Sounds workable right to me. But then again, a cherry-pick is also a
> case of rebase on a single commit, so we could be using rebase (and its
> recovery code) in cherry-pick, too, right?

Revert and cherry-pick are quite similar operation (the only
difference is that you swap his and pivot when doing revert), so
when you implement cherry-pick as an atomic operation you can
have revert almost for free.  If you have a rebase like you did,
it would be a bit more involved to make it do revert as well.