CODEWITHSUNDEEP
gitgithub
218
218

Reputation: 1824

git pull failing to pull changes from remote

My git log looks as follows:enter image description here

As I understand it origin/master and origin/HEAD are on the remote repository while master is on the local machine. A change was pushed to the repository (by me from another machine) creating commit 0e17adc. I now want to bring that change into my local repository. I thought the correct approach was to do:

git checkout master
git pull

However this returns:

Already up-to-date.

Why does this occur? master appears to me to be out of sync with origin/master and I thought git pull did a git fetch and then git merge so should merge origin/master with master?

Upvotes: 0

Views: 1435

Answers (1)

torek
torek

Reputation: 488183

As I understand it origin/master and origin/HEAD are on the remote repository while master is on the local machine.

This isn't quite right in detail (and the details matter) but it's backed by the right idea: origin/master is in your local machine, but it's your Git's way of remembering what your Git got from their (origin's) Git. When you run git fetch (or have git pull run git fetch), your Git calls up their Git at the URL your Git has stored along with the name origin. Their Git lists their master and its commit hash ID, and your Git make sure that you have the commit(s) required, and then sets your own origin/master to remember their master.

I now want to bring that change into my local repository. I thought the correct approach was to do:

git checkout master
git pull

That's one way that people typically do it. (I prefer to avoid git pull myself and break out the individual commands.)

However this returns:

Already up-to-date.

If you run git branch -vv (verbose twice: very verbose) you should see something similar to this, but different (this is in a Git repository for Git):

* master          5be1f00a9 [origin/master] First batch after 2.16

The thing in square brackets here, origin/master, is the current upstream setting for master. Each branch can have one (and only one) upstream, which you can set with git branch --set-upstream-to.

When you run git pull (or break it down into its components as I do), Git:

  1. runs git fetch: the other Git to fetch from defaults to the current branch's upstream's remote, in this case the origin part of origin/master; then
  2. runs a second Git command, usually git merge: the argument to this command depends on what your Git got from the other Git, plus the rest of the upstream setting.

There are, again, a bunch of finicky details that could matter, if some settings are badly broken, but in short, if git branch -vv shows origin/master as the upstream, then:

git fetch origin
git merge origin/master

should perform the equivalent of what happens when you run git pull ... and that should not result in the git log output you are showing in your image. So at this point my best guess is that the upstream of master is not set correctly.

You can run git branch -vv to view it, or use:

$ git rev-parse --symbolic-full-name "master@{upstream}"

which in my case prints:

refs/remotes/origin/master

(I put the quotes around master@{upstream} above because some command line interpreters do funny things with unquoted braces sometimes, but most of the time you should not need this).

If the upstream is wrong, and you're on master and want to fix it, run:

git branch --set-upstream-to=origin/master

This assumes your Git version is at least 1.8.0, when --set-upstream-to was added. In an older Git you can use:

git config branch.master.remote origin
git config branch.master.merge master

(the git branch --set-upstream command—note the lack of -to on the end here—is much too difficult to use correctly; avoid it).

Upvotes: 1

Related Questions