21

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?

Doug
  • 655
  • 2
  • 6
  • 15
  • You seem to have merged two commits that are themselves merges of the same two commits. As neither of those is a direct descendant of the other git *has* to make a commit when you ask it to merge. What I don't understand is why you wanted to do the same merge twice and then merge the result. What were you trying to do? – CB Bailey Nov 18 '10 at 21:41
  • 3
    1) Pulled from upstream [merged changes] 2) time passed, pulled from upstream again [merged more changes] 3) ready to push to my fork, pulled first (ensure there's no changes on the fork from coworkers) - no changes, yet empty merge commit written. `git pull --rebase` was exactly what I was looking for. – Doug Nov 20 '10 at 04:20

2 Answers2

26

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.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • 1
    Thank you. Also useful, your comment lead me here: [When should I use git pull --rebase?](http://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase) – Doug Nov 18 '10 at 21:16
6

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?

Community
  • 1
  • 1
nha
  • 17,623
  • 13
  • 87
  • 133