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

> 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*

>> 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?