117

In response to a question about pulling one commit at a time from a git repository, I was recommended to use git remote update instead of git fetch. I have read both man pages but cannot say I understood either in its entirety.

Can anyone explain to me how git fetch origin and get remote update origin behave differently?

Community
  • 1
  • 1
Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533
  • 4
    possible duplicate of [Differences between git remote update and fetch?](http://stackoverflow.com/questions/1856499/differences-between-git-remote-update-and-fetch) –  Jul 13 '13 at 20:05

1 Answers1

134

It makes no difference when used like this.

remote update is a very high-level command - it supports grouped remotes (remotes.<group> = <list>), and updating all remotes (except those with remote.<name>.skipDefaultUpdate set), but not any of the more specific options of fetch. Under the hood, though, it does the exact same thing as fetch with the default options.

The answer recommending remote update instead of git fetch was actually recommending it without a remote name, just for the sake of fetching all, not just the one named as an argument. This is equivalent to git fetch --all.

I should add the caveat that fetch and remote update didn't actually use the same codepath until v1.6.6.1 (released December 23 2009). Even before that, though, they did essentially the same thing, just using different code (possibly behaving slightly differently in corner cases, but I can't think of any off the top of my head).

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 1
    Very interesting. +1. If you look at the Git release notes (that I have compiled here: http://pastebin.com/LNhRhQS3), it seems that only the 1.7.0 (just after 1.6.6.2) allows "`git fetch --all`" to be used in place of "`git remote update`". – VonC Apr 22 '10 at 05:28
  • Ah, I didn't actually check when `fetch --all` went in. I do all this just by variations of `git log --grep=...` and `git describe --contains` in my git.git clone. – Cascabel Apr 22 '10 at 05:30
  • Hm, well that's weird - commit 9c4a036b is "Teach the --all option to 'git fetch'", and git describe --contains gives `v1.6.6.1~1^2~9`. (Same release as the remote update change I mentioned in my answer, updated to add the minor release version there). Maybe it was just late getting into the release notes? – Cascabel Apr 22 '10 at 05:33
  • @Jefromi: nice way to dig that information out, but I prefer to look first at the release notes and was frustrated by the lack of *one* page for all release notes, hence my little copy-paste in pastebin. – VonC Apr 22 '10 at 05:35
  • @Jefromi: right... now I have to find a way to aggregate all the "what's cooking in Git" in order to see why commit 9c4a036b didn't make it in the official release before 1.7 ;) – VonC Apr 22 '10 at 05:38
  • @VonC: Yeah, your approach is a lot more user-friendly. I'm just one of those people who has nothing better to do than skim the commit logs every time I pull, looking for exciting new features, so I usually have a pretty good idea what to look for. Best of luck to you digging around in the "what's cooking"! – Cascabel Apr 22 '10 at 05:41
  • Jefromi: "dig done" (that's a nice ring to it, too, even though "digging done" would be more correct). http://marc.info/?l=git&m=125919742432161&w=4 graduate the common path for fetch and remote update to master. the --all were announce as early as the first 1.6.6rc (http://marc.info/?l=git&m=125979629515276&w=4). – VonC Apr 22 '10 at 05:56
  • I see you're all just as OCD about logs and release notes as I am ;) –  Jul 13 '13 at 20:13