0

I see everywhere that a pull is a fetch + a merge. But if I explicitly specify the source branch, as in

(1) git pull origin somebranch

versus

(2) git fetch origin somebranch
    git merge origin/somebranch

only invocation (2) updates my remote tracking branch. Invocation (1) only updates FETCH_HEAD before merging into my current branch. Both behaviors are consistent with their respective documentation. They just aren't consistent with each other (in the case that the source branch is specified).

In the case of pull, what is the motivation for skipping the remote tracking branch? Why would I want to leave my remote tracking branch behind my local branch?

The second example of the 1.8.4 git-pull man page confirms the behavior that no remote tracking branches are updated. But it doesn't explain why.

pglezen
  • 961
  • 8
  • 18
  • possible duplicate of [What's the difference between 'git pull' and 'git fetch'?](http://stackoverflow.com/questions/292357/whats-the-difference-between-git-pull-and-git-fetch) – Carlos Campderrós Nov 08 '13 at 09:12
  • This question is a bit more subtle than pull versus fetch (namely the merge step). That one is indeed answered at great length in the cited post. My inquiry addressed the fetch step in particular common to both operations. – pglezen Nov 08 '13 at 13:07

2 Answers2

1

I think the most sensible explanation for "why" is "hysterical raisins", er, Historical Reasons. :-)

This gets mentioned in passing in 'git pull origin mybranch' leaves local mybranch N commits ahead of origin. Why? and git pull origin master does not update origin/master?: When git pull invokes git fetch, it passes arguments that prevent git fetch from updating refs/remotes/remote/branchname. [Edit: as Charles Bailey notes, this historical oddity is now fixed, as of 1.8.4.]

The rather awkward and complicated mapping of branch.name.remote and branch.name.merge to refs/remotes/remote/branch for tracking branches complements the awkwardness of the way git pull fails to update remote-branch heads (if that makes any sense :-) ).

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
  • Now that you mention it in that way, it does make more sense. As I studied the git-pull docs, I noticed one had to be careful about placement of "fetch" versus "merge" options on the command line; probably another symptom of that awkwardness. – pglezen Nov 08 '13 at 13:02
1

The behaviour of git fetch changed in 1.8.4. Now, an explicitly mentioned ref has it's local tracking ref updated if such a ref exists.

This is the change, which was mentioned in the release notes.

I have tested and git pull origin master does now update my origin/master tracking ref and is still consistent with the new behaviour of git fetch origin master.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • Thanks, Charles. I updated to 1.8.4 only a few days ago. Indeed, the behavior I recounted applied to an earlier 1.8 release. So my post was a bit misleading: I related docs from 1.8.4, but behavior from an earlier 1.8 release. – pglezen Nov 08 '13 at 12:58