Re: Merging using only fast-forward

From: Sverre Hvammen Johansen <hvammen@gmail.com>
Date: Jan 19, 2008, 10:28 UTC
Message-ID: <402c10cd0801190228o68995493u9b8b40e1557092dd@mail.gmail.com>
In-Reply-To: <7vodbibzch.fsf@gitster.siamese.dyndns.org>

On Jan 18, 2008 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> ...
> 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