Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 1, 2013, 15:38 UTC
Message-ID: <7vmwq6i93m.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51D197AD.1070502@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 6 quoted lines

> So I think that command invocations with more than one of {"--ff",
> "--no-ff", "--ff-only"} should respect the last option listed rather
> than complaining about "cannot combine options".
>
> If I find the time (unlikely) I might submit a patch to implement these
> expectations.

And I wouldn't reject it on the basis of the design --- I agree fully with your analysis above. Thanks for digging and spelling out how they should be fixed.

As to "--no-ff" vs "--ff-only", "--ff-only" has always meant "only fast-forward updates are allowed. We do not want to create a merge commit with this operation." I do agree with you that the proposed patch changes the established semantis and may be too disruptive a thing to do at this point.

> In my opinion, your use case shouldn't be supported by the command
> because (1) it is confusing, (2) it is not very common, and (3) it is
> easy to work around:
> ...

If one were designing Git merge from scratch today, however, I could see one may have designed these as two orthogonal switches.

 - Precondition on the shape of histories being merged ("fail unless
   fast forward" does not have to be the only criteria);

 - How the update is done ("fast forward to the other head", "always
   create a merge", "fast forward if possible, otherwise merge" do
   not have to be the only three choices).

I do not fundamentally oppose to such a new feature, but they have to interact sanely with the current "--ff={only,only,never}".