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

Re: [RFC/PATCH] Fast forward strategies only, common, fork and path

From: Sverre Hvammen Johansen <hidden>
Date: 2016-06-15 22:44:10

On Feb 4, 2008 12:22 AM, Junio C Hamano [off-list ref] wrote:
The documentation updates talked about what the options do, but
it was unclear why they could be useful in what situations and
workflows.  At least it was not apparent to me on my cursory
read.
Common, fork, and path only make sense where there are at least three
repositories or two plus an observer involved.

Lets explain the observer cases.

The observer is interested in changes that X, Y and Z agree upon.  He
can merge as follows:

  git merge --ff=common X Y Z

The observer is interested in changes up to the point where someone is
known to disagree.  He can merge as follows:

   git merge --ff=fork X Y Z

 The observer is interested in any give path up to one of the true
parents.  He can merge as follows:

  git merge --ff=path X Y Z

This will give priority to X then Y.

This + only are all the interesting cases for fast forward.  Some work
flows between more than two repositories in the general case would
require additional features for rebase:  Rebase on any patch, the fork
point, or common ancestor of the remote branches.  This is something I
would like to discuss at some later time.
quoted
--ff=never will turn this off together with fast forward.  Maybe we
should have --ff=traditional that is the old behavior.
Sure, and I mildly suspect that it should be the default.
I would argue that it should not be the default, simply because we
already use the real parents when only two branches are involved, This
is most convenient for most users.   Exactly the same argument holds
when there are more than two branches involved.  The history may be
simplified in a similar way.   Most projects would however not care
simply because they never merge more than two branches.   It is quite
common to have one topic branch that is based on the tip of another
topic branch and if those are merged back to the main branch you would
like it to be reduced down to two real heads (or even a fast forward),
exactly as one branch would result in a fast forward if it happened to
be based on the tip of master.

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