Magit: --ff-only and --no-ff are not incompatible

[ipburbank]

The following commit disallowed enabling ff-only and no-ff:
https://github.com/magit/magit/commit/6e6e35488c3a463d586ec84442f463213bf9ce4a#diff-04d899c618bdf6e64d4e8f6a6815c377R43

From the git man pages:

With --no-ff, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.
With --ff-only, resolve the merge as a fast-forward when possible. When not possible, refuse to merge and exit with a non-zero status.

While that is ambiguous as to whether the combination should be allowed, I believe this test case from the git repository shows the intended behavior is to allow them in one order but not the other:
https://github.com/git/git/blob/a6a95cd1b46e48e5fe06bdbb0839a67ebeef4682/t/t7600-merge.sh#L579

Proposed solution: Magit should allow the combination of --no-ff and --ff-only

[phil-s]

From my reading the two options are incompatible, but on the command line git allows --ff-only to take precedence over --no-ff, such that the latter does not affect the command at all -- as if it wasn't specified.

Is it a problem if Magit makes the conflict more apparent to the user?

It seems to me like a less-confusing approach (especially if the order of arguments is important, because in Magit the user can't see what that's going to end up being).

If the issue is that having one of them selected by default makes it more irritating to choose the other option, then perhaps some kind of radio-button behaviour could be a solution, such that selecting one de-selects the other? (Edit: in fact, as indicated by @kyleam, that radio-button approach is precisely how current versions of Magit behave; so enabling one of these options by default should not cause any unnecessary friction when the other option is wanted.)

[kyleam]

Like @phil-s, I'm not seeing what the problem is here. While Git has a lot of mutually exclusive options and generally follows a last one wins policy, I think that it'd be confusing and pointless to try to map that behavior to transient. There would have to be a way for the user to know and control the order of the arguments. That'd complicate the interface for no good reason because the current behavior already nicely captures and presents the overriding behavior. If you have --ff-only selected and then choose --no-ff, --ff-only is deselected, effectively overriding it right there in the transient.

[ipburbank]

Consider me convinced.