Git: pull vs. fetch→pull

Question

I've never been able to get a clear answer to this question.

For a long time, and at the advisement of a coworker, I've been doing this:

git fetch origin
git pull origin <mybranch>

I've been told (and have seen) that git pull does not behave the same way if you do not first do git fetch. You don't get any remote changes.

But all I see online is that git pull is the equivalent of git fetch followed by git merge. If that were true, git pull would include git fetch, and I wouldn't need an explicit git fetch first, right? But that doesn't seem to be the case.

So what I'm looking for is some explicit documentation that describes the observed behavior of git pull. (I know I'll probably also get lots of advice to switch to git fetch → git merge; that's fine too, but I'm really interested in git pull.)

Answer 1

We should probably close this as a duplicate, but before that happens, let me see if I can squeeze this in.

While git pull really is git fetch followed by git merge (or git rebase), the precise difference lies in how git pull runs git fetch.

Specifically:

$ git pull

or:

$ git pull remote-name branch-name

(or various similar variants) runs, not plain git fetch, not git fetch remote-name, but git fetch remote-name branch-name.

This has less difference, since Git version 1.8.4, than it did before that version:

• git fetch origin master unlike git fetch origin or git fetch did not update refs/remotes/origin/master; this was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient to opportunistically update them whenever we have a chance, and we have been updating them when we run git push which already breaks the original "predictability" anyway.

In other words, if git pull decides to run git fetch origin master, this will update origin/master in your repository—but only if you are not running ancient versions of Git such as those included in certain unnamed Linux distributions.

If you run git fetch origin, you will get all remote-tracking branches updated (provided you have a reasonable configuration, which is the default even in said ancient versions of Git). If you run git fetch origin master, you will only get origin/master updated, and again only if your Git is not too ridiculously out of date. Since git pull runs the four-word variant, it updates only one, or even no, remote-tracking branches.

Answer 2

I've been told (and have seen) that git pull does not behave the same way if you do not first do git fetch. You don't get any remote changes.

Usually, that's not true, and git pull pulls the state from the remote.

But all I see online is that git pull is the equivalent of git fetch followed by git merge. If that were true,

it is!

Citing the manual page of git-pull:

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

I think that settles it.

So what I'm looking for is some explicit documentation

$ git help pull

Answer 3

git pull is a get fetch followed by a git merge. (or you can rebase instead with the --rebase option). So no you don't need to do 'git fetch' before a 'git pull'

type 'git help fetch' and 'git help pull' for descriptions

git fetch goes to the named repository, gets the object that is referenced (typically a commit), gets it and all it's dependent objects, and stores it in the named remote tracking branch. You could then merge or rebase from there. 'git merge origin/master' or you could just view it with 'git checkout origin/master'