--no-commit option does not work.

--no-commit option does not work.

[BongHo Lee]

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

Re: --no-commit option does not work.

[Junio C Hamano]

BongHo Lee <techcap@live.com> writes:

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

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.