Well, a couple of things. If you look at a branching model such as that described by Vincent Driessen [1], you start to appreciate the amount of information enc

Well, a couple of things. If you look at a branching model such as that described by Vincent Driessen [1], you start to appreciate the amount of information encapsulated by branches and merges in the history. In a fast-moving project with several developers, glancing at the history becomes the easiest way for each developer to keep track of what the rest of the team has been working on. Thus, anything that introduces noise to the history reduces the value of the information it contains. But 'git pull' is even worse than this - it actually creates 'misleading' history: Each merge commit has (at least) two parents, the first of which is special in a subtle way - it's the commit you were _on_ when you merged the changes _in_. So, with a nice history, you can follow a branch back in time by following the first parent of each commit. When you 'git pull', the merge commit has your local changes as the first parent, and the rest of the team's changes look like a separate chunk of work merged in. Git-bisect is an extremely useful tool for searching the history for the commit that introduced a problem, but a history full of misleading merges dramatically reduces its usefulness. Still, YMMV, the costs of keeping a good history may outweigh the benefits for you and your team. For me and mine, it's definitely worth it. [1] http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/