Re: [PATCH] Adding rebase merge strategy

Tom Clarke [off-list ref] wrote:

On 10/2/07, Carl Worth [off-list ref] wrote:

quoted

What I think I've always wanted is something like the following
behavior for "git pull":

  * Fast forward if possible

  * Otherwise, rebase, but only if there are no conflicts at all

  * Otherwise, do the merge as normal, (leave conflict markers in
    place allowing the user to fix them up and then commit).

Would it be straightforward to turn your rebase merge strategy into
something like the above? And if so, would that address the primary
concerns that Junio raised?

Maybe we need a 'pull' strategy' - merge, rebase or <insert name for
strategy you describe above>.

`git pull -s <name>` takes any merge strategy that git-merge will
accept for its -s option.  There is also the config option of
pull.twohead that indicates what the default merge/pull strategy
should be for a two head merge.  Most people don't set this,
letting the code default to 'recursive'.

But I have to agree with (was it Junio who said this?) doing a rebase
in a merge strategy doesn't make sense when conflicts come into play.
It gets confusing fast for the end-user as the conflict resolution
process is different than for a merge.  A long time ago I wrote a
git-merge-rebase strategy and gave up on it for basically the same
reason.  I posted it to the mailing list and I think Linus said
"Why?!".  That was the end of that thread as I wound up agreeing
with him.

Multiple merge strategies can be given (and attempted).  A rebase
strategy could be attempted before recursive, and if the rebase
fails but the recursive succeeds then you get (roughly) what is
being described above by Carl.  But that still requires a rebase
merge strategy.  :-\

-- 
Shawn.