Re: Unexpected or wrong ff, no-ff and ff-only behaviour

From: Roland Jäger <eyenseo@mailbox.org>
Date: Jul 9, 2019, 16:15 UTC
Message-ID: <1152121968.7459.1562688927235@office.mailbox.org>
In-Reply-To: <xmqqa7dnw9b1.fsf@gitster-ct.c.googlers.com>

Thanks for answering Junio.

I get what git does. But I believe that either the documentation ist wrong/ambiguous or --no-ff and --ff-only should be able to be combined and either should be fixed - preferably the later. What I want to say to git is "I never accept a real merge; please make a merge commit, even if it is redundant/empty". And I believe that github and gitlab allow to configure something like that.

My manpage tells me the following:

--ff When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior. => Allow either

--no-ff Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag that is not stored in its natural place in refs/tags/ hierarchy. => Always create a commit, even when FF

--ff-only Refuse to merge and exit with a non-zero status unless the current HEAD is already up to date or the merge can be resolved as a fast-forward. => Fail if FF is not possible

man page: On 9 July 2019 16:51:14 CEST, Junio C Hamano <gitster@pobox.com> wrote:> usbuser@mailbox.org writes:

Show 25 quoted lines

> 
> > I'm rather confused about --ff, --no-ff and --ff-only. They seam
> >      
> > to be all mutual exclusive...
> A clean result left by "git merge" can be either a fast-forward, or
> a real merge (i.e. 2 possible outcomes).
> 
> The --ff option lets you say "If the other history I am attempting
> to merge is a descendant of the current commit, not creating a real
> merge and instead fast-forwarding is permitted".  As this is the
> default, case you actually type --ff on the command line is rather
> limited (e.g. to countermand an earlier --no-ff on the command
> line).
> 
> The --no-ff option lets you say "I never accept a fast-forward as
> the result; please make a real merge instead, even if it is
> redundant".
> 
> The --ff-only option lets you say "I never accept a real merge as 
> the result; please fail if this does not fast-forward".
> 
> So, the only "real" options are between --[no-]ff (which allows or
> disallows one of the two possible outcomes, which is "fast-forward")
> and [--ff-only] (which allows or disallows the other one of the two
> possible outcomes, which is "real merge").