Tom Clarke <tom@xxxxxxx> wrote: > On 10/2/07, Carl Worth <cworth@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
