Prevent git from writing empty merge commits

Question

Accustomed to SVN, I always do an 'update' before sharing any changes, so before making any pushes I always pull first.

It's annoying when I pull (even though there weren't any changes to the remote) and see a commit for a merge with 0 changed files with 0 additions and 0 deletions. Commits like:
https://github.com/UCF/Harvard-Mobile-Web/commit/be9d6b2d1ab196554e080d8b8647a9d16c8a5ddf

I find this to be useless noise when looking at the commit history.

Maybe there's something I'm missing, is there any point to this commit? If not, is there any way to prevent git from writing empty merge commits?

Answer 1

The very definition of git pull is essentially "fetch and merge with the new remote HEAD for my current branch." If you want to rebase instead, just git pull --rebase. This modifies pull to rebase your commits on top of the new remote HEAD.

Personally, I like to git fetch (download new objects from the remote, but do not update any local branches) and inspect the situation, then decide myself whether to merge or rebase.

Answer 2

There are several options, all coming down to the same thing : making git use the --rebase option (as mentioned by @cdhowie).

You will probably find that you prefer one of those:

Option 1: Explicitly use git pull --rebase every time.

Option 2: for each project, modify the .git/config file by adding

[branch "master"]
 remote = origin
 merge = refs/heads/master
 rebase = true

Option 3: in your personal ~/.gitconfig

[branch]  
  autosetuprebase = always

Personally I like option 3, since it allows me not to enforce anything on other developers, while still not having to type --rebase every time.

Also see How to make Git pull use rebase by default for all my repositories?