--no-commit option does not work.

Setup Version : git version 2.12.1.windows.1

OS Version : Microsoft Windows [Version 10.0.14393]

Options $ cat /etc/install-options.txt Path Option: Cmd SSH Option: OpenSSH CURL Option: OpenSSL CRLF Option: CRLFCommitAsIs Bash Terminal Option: MinTTY Performance Tweaks FSCache: Enabled Use Credential Manager: Enabled Enable Symlinks: Disabled

Git Command : git merge --no-commit origin/workingBranch

. What did you expect to occur after running these commands? merge but no commit. . What actually happened instead? commited

Reference URL : https://github.com/techcap/nf-interpreter

Details I tried to merge from MergeTest to master. After checking out master, I run below command.

C:\work\nf-interpreter-techcap>git branch
  MergeTest
  TemplateModification
  UpdateBuildInstruction
* master

C:\work\nf-interpreter-techcap>git merge --no-commit origin/MergeTest Updating 197ad33..028f9f5 Fast-forward mergeTest.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 mergeTest.txt

C:\work\nf-interpreter-techcap>git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

If I add --no-ff option, it works properly. I think --no-commit option should be worked without --no-ff.

https://github.com/git-for-windows/git/issues/1102#issuecomment-289206961

BongHo Lee <techcap@live.com> writes:

It is understandable that this is confusing, but --no-commit is an instruction not to create a new commit object. As fast-forwarding to the commit that is a strict descendant of your old tip does not involve creation of any new commit, the command is working exactly as instructed. If you say "--no-ff", you are explicitly forbidding the command to fast-forward, so the command attempts to create a (needless) new commit that is a merge, and then --no-commit stops the command after it prepared the tree state ready to be committed.

So with or without --no-ff, the option and the command are working correctly.

Having said all that, my gut feeling is that a backward incompatible change to make --no-commit "imply" --no-ff may not hurt too many existing users, but I am saying this without thinking things through. I may very well be missing a valid use case where --no-commit that does not fail but does fast-forward when the user does not give --no-ff is useful, so if that is the case, such a change will be breaking those users.