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@xxxxxxxxx> wrote:> usbuser@xxxxxxxxxxx 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").