37

According to the documentation, git pull performs a git fetch then a git merge, however in that case performing git pull origin master should perform a git fetch origin master right? However, it does not appear to be doing so. Here is an example.

Supposed my remote origin master (on GitHub in my case) has the following history:

commit 1111111 : my first commit
commit 2222222 : a commit from someone else

and I only have my first commit locally as doing following shows

git checkout master
git log --pretty=format:'%h' -n 1
1111111

git checkout origin/master
git log --pretty=format:'%h' -n 1
1111111

From here I do my pull and look at the results as follows:

git checkout master
git pull origin master

git log --pretty=format:'%h' -n 1
2222222

git checkout origin/master
git log --pretty=format:'%h' -n 1
1111111

As can be seen, the pull did in fact update my master branch with the new commit(s) from the remote origin, but my local origin/master is still where it was. Forcing me to do the following

git fetch origin master

git checkout origin/master
git log --pretty=format:'%h' -n 1
2222222

Is this correct behavior for git pull or might I have something miss configured? I looked through the git pull man page and didn't see anything that suggested this but I may have missed it.

Kenneth Baltrinic
  • 2,855
  • 2
  • 24
  • 45
  • see if this helps explain why to you. http://stackoverflow.com/questions/2452226/master-branch-and-origin-master-have-diverged-how-to-undiverge-branches or this one http://stackoverflow.com/questions/2883840/differences-between-git-pull-origin-master-git-pull-origin-master – carbonbasednerd Dec 31 '11 at 16:06
  • 1
    possible duplicate of ['git pull origin mybranch' leaves local mybranch N commits ahead of origin. Why?](http://stackoverflow.com/questions/1741143/git-pull-origin-mybranch-leaves-local-mybranch-n-commits-ahead-of-origin-why) – CB Bailey Dec 31 '11 at 22:22
  • You might want to consider doing `git fetch` followed by `git merge`. You'll generally end up with less surprises and have more control over how to merge. – Michael Mior Jan 01 '12 at 14:18
  • @CharlesBailey Yes, I concur that Matthias and I are discussing the same problem. Too bad his question didn't come up in my earlier searches. – Kenneth Baltrinic Jan 02 '12 at 19:55

3 Answers3

29

It's a bit weird, but if you use git pull [remote] <refspec> it actually doesn't update the remote refs. It sort of makes sense if you think about it a certain way: since you're specifying a specific ref to fetch, it doesn't have to look up anything about your remote branches, so it doesn't inherently know what remote branch it should update. It of course could figure it out, and I wouldn't be surprised if it gets fixed eventually, but that's the existing behavior. (There may be messages on the mailing list about it - I don't know.)

You can easily work around it, though. If you use git pull origin/master, since you're specifying what to fetch via a remote branch, it should update that remote branch. And if you're on your master branch anyway (or any other branch tracking origin/master), you can just do git pull and let it fill in the defaults, and it will update remote branches.

This is documented in the git-pull man page, most concisely under EXAMPLES but also elsewhere. The relevant part:

Merge into the current branch the remote branch next:

$ git pull origin next

This leaves a copy of next temporarily in FETCH_HEAD, but does not update any remote-tracking branches. Using remote-tracking branches, the same can be done by invoking fetch and merge:

$ git fetch origin
$ git merge origin/next
Community
  • 1
  • 1
Cascabel
  • 422,485
  • 65
  • 357
  • 307
  • It's buried somewhere in the `git-pull` manpage, I think. I'll try and hunt it down sometime later if I remember. – Cascabel Jan 02 '12 at 20:27
  • @KennethBaltrinic: It's in the examples section, and can be deduced from the rest of the documentation as well. – Cascabel Jan 03 '12 at 01:22
  • 4
    The workaround seems not to work for me: `git pull --rebase origin/master` says `origin/master not a remote repo`. And `git pull --rebase origin origin/master` couldn't find `git pull --rebase origin/master` – m-ric Jun 13 '13 at 20:36
  • `git fetch origin` did the job. Thank you. – rmagnum2002 Apr 24 '15 at 08:19
0

it seems you have forked the repository and your forked branch is not updated with the latest code

Nishant Ranjan
  • 21
  • 8
0

I had this issue also - where I ran "git pull" while on a branch then checked the log and it had not been updated. Confused I actually read the output from the git pull and it speciically mentions you need to tell git where to merge and this is done by a command along the lines of "git pull [remote] [local branch]" ie for me it was "git pull origin newfeature1".

First command attempt with issue:

Z:\Abusers\jd\repo1> git pull
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 16 (delta 7), reused 15 (delta 7), pack-reused 1
Unpacking objects: 100% (16/16), done.
From github.abc.com:group1/repo1
   06aefba..e5ed6ee  develop    -> origin/develop
   af689cb..b8667a6  newfeature1-> origin/newfeature1
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> newfeature1

Working command:

Z:\Abusers\jd\repo1> git pull origin newfeature1
From github.abc.com:group1/repo1
* branch            newfeature1-> FETCH_HEAD
Updating af689cb..b8667a6
Fast-forward
.../file1.py                |   2 +-
abc/yes1/cool1.a        | Bin 0 -> 106329 bytes
.../abc.py                    |   7 ++++---
3 files changed, 5 insertions(+), 4 deletions(-)
create mode 100644 abc/yes1/cool1.a
John Drinane
  • 595
  • 6
  • 20