Re: [RFC/PATCH Second draft] Fast forward strategies allow, never, and only

["Sverre Hvammen Johansen" <hvammen@gmail.com>]

On Wed, Mar 19, 2008 at 1:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:

>  > +The following shows master and three topic branches.  TopicB is based
>  > +on TopicA, TopicA is previously branched off from master, and TopicC
>  > +is based on the current `HEAD` of master:
>  > +
>  > +------------
>  > +                    o---o---o  TopicB
>  > +                   /
>  > +          o---o---o  TopicA
>  > +         /
>  > +    o---o---o---o---o---o  master
>  > +                         \
>  > +                          o---o  TopicC
>  > +------------
>
>  I'd provide first simpler example without 'TopicC'.

If we are to explain how this is recorded this is how simple we can
make it without leaving anything out.  However, I am not sure we
should have this in the documentation at all.  Most users probably
don't care exactly how this is recorded as long as the history down
the road is not to complicated.

>  If I understand correctly you have implemented here always using
>  "parent" (or "dependent") reduction of merge heads. IMHO this reduction
>  contradict stated idea of using --ff=never (--no-ff) to always mark
>  where topic branch has ended.

When using --ff=never this reduction will not be done and that is also
how current git works (except that you need to say --no-ff).

>  > +         % git co master
>  > +         % git merge TopicA TopicB TopicC
>  > +
>  > +                    o---o---o  TopicB
>  > +                   /         \
>  > +          o---o---o  TopicA   \
>  > +         /                     \
>  > +    o---o---o---o---o---o.......o  master
>  > +                         \     /
>  > +                          o---o  TopicC
>  > +------------
>
>  This... is a bit unexpected. I thought that there should be line where
>  I have added dotted line.

The graph also describes how current git record this.  Try the example
and see for yourself.  The main difference between the patch and
current git is that the patch is trying to be smarter about how it
selects the merge algorithm, and which commits are passed on to the
real merge algorithm.  In the example above it makes no difference
since octopus is used and whether octopus is getting three or four
branches does not matter at all since the octopus merge is able to do
this reduction internally.  But in the case where we end up with two
branches it makes a huge difference since we then can use the more
smarter merge algorithms, and more cases will be merged automatically.
 However, all this does not make much of a difference in most cases.
Git rocks whether we decide to do this or not.

>  I'd really prefer if you would resurrect merge head reduction options
>  (strategies?) as it was, i.e. as separate patch. And of course talk
>  about reducing heads, not fast-forward options/strategies... this issue
>  is IMVHO orthogonal to options for allowing/forcing/denying fast-forward.

The first patch had the same features, was implemented slightly
differently, but lacked a lot of documentation.

-- 
Sverre Hvammen Johansen