Junio C Hamano <gitster@xxxxxxxxx> writes:
> Andrew Ardill <andrew.ardill@xxxxxxxxx> writes:
>
>> I do think that the --no-commit option should imply --no-ff (as this
>> would make the behaviour consistent for end-users). I don't know if
>> this is something that would break scripts etc, but if so you could
>> make it implied only if we detect a terminal or something like is done
>> in other places.
>
> But we are not living in that world. Making "--no-commit" (which is
> not that "try to populate and show" command) imply "--no-ff" will
> break existing scripts....
Having said all that, there is one change we might want to consider,
with a plan to transition to cope with backward incompatibility.
A user who uses "--no-commit" does so with the intention to record a
resulting merge after amending the merge result in the working tree.
But there is nothing to amend and record, if the same "git merge"
without "--no-commit" wouldn't have created a merge commit (there
are two cases: (1) the other branch is a descendant of the current
branch, (2) the other branch is an ancestor of the current branch).
And the user would want to know that before doing further damange to
his history, so we may want to start warn when "--no-commit"
fast-forwarded or succeeded with "already up-to-date", with
deprecation notice, and eventually want to make it an error.
Those who want to do a scripted
git merge --no-commit "$1" &&
autoedit "$1" &&
git commit
(where the script takes a branch name $1 and uses auto-edit to
further record the fact that a branch $1 was merged to somewhere in
the contents) would already be buggy if it wants to force no-ff, and
will get a warning (and later an error), with such a change. And
fixing the script to add "--no-ff" next to "--no-commit" will also
stop the new warning/error.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html