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

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >>  - You kept the original "format-patch piped to am" workflow
> >>    optionally working.
> >
> > I left it as the default, too.  I figured that it's best not
> > to change the default (and most likely faster) behavior of
> > something people rely on.
> 
> I should have said: "You kept ... working, which is good".
> 
> >> I think the three-way merge you would want here is not between B
> >> and G using E as the pivot, but between B and G using A as the
> >> pivot.  That's how cherry-pick and revert works.  I would
> >> leverage the interface that is one level lower for this -- the
> >> strategy modules themselves.
> >> 
> >> 	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.

> > I'm not an expert at merging strategies by any measure, I've just
> > trusted merge-recursive to Do The Right Thing(TM) more often than not,
> > and use rerere to avoid repeating work.
> 
> 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?