Re: Unexpected or wrong ff, no-ff and ff-only behaviour
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 9, 2019, 14:51 UTC
- Message-ID
- <xmqqa7dnw9b1.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <423596682.8516.1562665372094@office.mailbox.org>
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").