1.6.1.3: git merge --no-commit ... DID commit

quadra% git merge --no-commit duane-acl82/acl82
Updating 621f935..a94f7fc
Fast forward
 ChangeLog               |   23 ++++++++++++++
 src/c/fio.c             |    2 +-
 src/c/mon1.c            |    6 ++-
 src/code/debug.cl       |   10 +++++-
 src/code/lldb.cl        |   75 +++++++++++++++++++++++++++++++++++++---------
 src/code/osi-alpha.cl   |   33 ++++++++++++++++++++
 src/code/osi-alpha64.cl |   33 ++++++++++++++++++++
 src/code/x/disx86-64.cl |    4 ++
 src/rs/vrlinux.cl       |    3 +-
 src/rs/xrlinux64.cl     |   30 +++++++++++++++----
 src/rs/xrmacosx64.cl    |   44 ++++++++++++++++++++++++----
 src/rs/xrms64.cl        |   28 ++++++++++++++---
 src/rs/xrsol64.cl       |   28 ++++++++++++++---
 13 files changed, 276 insertions(+), 43 deletions(-)
quadra% git status
# On branch acl82
# Your branch is ahead of 'origin/acl82' by 2 commits.
#
nothing to commit (working directory clean)
quadra% 

Has this been fixed in a later version?

layer <layer@known.net> writes:

In short, there is nothing to fix. You asked it not to create a commit, and the merge was a fast-forward; there was no new commit created.

When a real merge is involved, e.g. you have this history:

         x---x---x---x---B duane-acl82/acl82
        /
    ---O---o---o---o---A HEAD

telling "--no-commit" to merge creates the state to be committed in your work tree and the index, notes the fact that the next "git commit" will record a merge between A and B, and stops. Hence, "git diff HEAD" will show the damange merging duane-acl82/acl82 will cause to your current branch, and then you can "git commit" to record the merge to result in this history:

         x---x---x---x---B duane-acl82/acl82
        /                 \
    ---O---o---o---o---A---* HEAD

A --no-commit merge followed by committing on your own will result in a history of the same shape as "merge" without --no-commit will create.

Think what you want to happen if you started from this history:

         x---x---x---x---B duane-acl82/acl82
        /
    ---A HEAD

If "merge --no-commit" left HEAD at A but updated the index and the work tree to the result of the merge, which would be the same as the tree recorded by commit B, and prepared to record a merge commit between A and B, then next "git commit" will not create a history of the same shape as you would normally get from "merge" without --no-commit, which is:

                           HEAD
         x---x---x---x---B duane-acl82/acl82
        /
    ---A

Instead, you will end up with a history of this shape, with one useless merge commit:

         x---x---x---x---B duane-acl82/acl82
        /                 \
    ---A-------------------* HEAD

That is why "merge --no-commit" will fast-forward.

If you really want to do this, there is a way to create a history with such a shape ("git merge --no-ff") but by default it is not recommended and you need to explicitly ask for it (or configure). It can also be used together with --no-commit option.

Often people claim that they want to review before actually merging, but it is much better to get in the habit of running "git merge topic" first then inspecting "git diff ORIG_HEAD^ after the fact. If the result is undesirable, you can always "git reset --hard ORIG_HEAD" it away. The reason it is better is that this will work regardless of the kind of merge you would end up with; you can reset away a fast-forward using ORIG_HEAD.

Another technique that may be worth learning is to do "git diff ...topic" before running a merge (notice three dots).