Re: Merging using only fast-forward

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

On Jan 18, 2008 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
> So keep it simple, and do not use Octopus if there is no
> justification other than "it looks cool" you can come up with.
>
> I do not mind a patch to git-merge-octopus to discurage its use
> even more by detecting the casen where some of the merged
> branches are not independent and refusing to work, but that is
> a post 1.5.4 topic.

Instead of refusing to work, such merge commits can be fast forwarded,
recorded as a "normal" commit with two children, or an octopus with
fewer children than those specified by the user.

The more I think about this is that --ff-only should really be
specified as a merge strategy (single) and not as an special case of
--ff.  All merge strategies can then take any number of commits, but
will only succeed if the commits can be reduced down to two or fewer
for resolve/recursive and one for single.

Commit reduction is simpler for single than the other merge strategies.

I suggest we keep it simple and implement this new feature as a merge
strategy and the commit reduction is only done for fast-forward.

I will create a good number of test cases so we should be comfortable
with this new feature.

A later patch will implement the commit reduction for the other merge
strategies.  --no-ff will then have the meaning:  No fast forward of
any commit.  All commits specified by the user will be recorded.

-- 
Sverre Hvammen Johansen