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

["Roland Jäger" <eyenseo@mailbox.org>]

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:
> 
> > 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").