Michael Haggerty <[email protected]> writes:
> 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}".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
