‘git pull origin mybranch’ leaves local mybranch N commits ahead of origin. Why?

git pull calls git fetch with the appropriate parameters before merging the explicitly fetched heads (or if none the remote branch configured for merge) into the current branch.

The syntax: git fetch <repository> <ref> where <ref> is just a branch name with no colon is a ‘one shot’ fetch that doesn’t do a standard fetch of all the tracked branches of the specified remote but instead fetches just the named branch into FETCH_HEAD.

Update: for Git versions since 1.8.4, if there is a remote tracking branch which tracks the ref that you asked to fetch then the tracking branch will now be updated by fetch. This change has been made specifically to avoid the confusion that the previous behaviour caused.

When you perform git pull <repository> <ref>, FETCH_HEAD is updated as above, then merged into your checked out HEAD but none of the standard tracking branches for the remote repository will be updated (Git <1.8.4). This means that locally it looks like you are ahead of of the remote branch, whereas in fact you are up to date with it.

Personally I always do git fetch followed by git merge <remote>/<branch> because I get to see any warnings about forced updates before I merge, and I can preview what I’m merging in. If I used git pull a bit more than I do, I would do a plain git pull with no parameters most of the time, relying on branch.<branch>.remote and branch.<branch>.merge to ‘do the right thing’.

Leave a Comment