Question

In the following example, is there a way to know a merge happened? Looking at git log, I can’t tell I merged.

# setup example directory
$ mkdir test
$ cd test
$ git init
$ touch a
$ git add a
$ git commit -m "1"

# switch to different branch
$ git checkout -b topic
$ touch b
$ git add b
$ git commit -m "2"

# go back to master and merge
$ git checkout master
$ git merge topic

# git log

commit cccc64de3947828f487a8ce3c3e72b0f68dc88c3
Author: none
Date:   Fri May 20 05:54:45 2011 -0700

    2

commit a5d57454295759609d91a60219002e74016eed2b
Author: none
Date:   Fri May 20 05:54:29 2011 -0700

    1

Answer 1

In that instance, git has spotted that it’s possible to do a so-called “fast-forward” merge, since the branch you’re merging in already contains everything in the current branch – it doesn’t need to create a new commit in the commit graph to join the two branches.

If you don’t like that behaviour, and want create a merge commit even when fast-forwarding is possible, you should merge in the other branch with:

git merge --no-ff topic

However, if you really need to know whether a merge happened or not, you can find that information in the “reflog”. For example, in your situation, git reflog would produce the following output:

1eecbcb HEAD@{0}: merge topic: Fast-forward
193ae5e HEAD@{1}: checkout: moving from topic to master
1eecbcb HEAD@{2}: commit: 2
193ae5e HEAD@{3}: checkout: moving from master to topic
193ae5e HEAD@{4}: commit (initial): 1

… which shows you how HEAD was changed recently, and what action caused that to happen. However, relying on the reflog is generally a bad idea except in particular situations, such as recovering from errors – it’s better to just think in terms of the commit graph, and make that represent what you’ve done. git merge --no-ff is one such method that lots of people like.