Tom Clarke <tom@u2i.com> wrote:
quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html