Re: [PATCH] Adding rebase merge strategy

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 1, 2007, 22:30 UTC
Message-ID: <20071001223050.GE2137@spearce.org>
In-Reply-To: <550f9510710011521s126ca747v956a6f80182444bb@mail.gmail.com>

Tom Clarke <tom@u2i.com> wrote:

Show 17 quoted lines

> On 10/2/07, Carl Worth <cworth@cworth.org> wrote:
> > 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.