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

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

[layer]

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?

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

[Junio C Hamano]

layer <layer@known.net> writes:

> quadra% git merge --no-commit duane-acl82/acl82
> Updating 621f935..a94f7fc
> Fast forward
> ...
> quadra% git status
> # On branch acl82
> # Your branch is ahead of 'origin/acl82' by 2 commits.
> #
> nothing to commit (working directory clean)
> ...
> Has this been fixed in a later version?

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).