Thread (9 messages) flat view 9 messages, 6 authors, 2016-06-15

Re: [PATCH] Adding rebase merge strategy

From: Carl Worth <hidden>
Date: 2016-06-15 22:43:37

On Mon, 1 Oct 2007 23:41:56 +0200, "Tom Clarke" wrote:
Thanks for the ample feedback, you raise a number of interesting
issues. I am wondering now if making rebase a merge strategy is really
a good idea. Rebasing is not merging, a difference that could perhaps
be overlooked in the no-conflict scenario, but as you point out, is
glaringly obvious as soon as you have conflicts.
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?

-Carl

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help