tags:

views:

982

answers:

3

A nice and simple question - is the function of "git fetch" a strict sub-set of "git fetch --tags"?

I.e. if I run "git fetch --tags", is there ever a reason to immediately run "git fetch" straight afterward?

What about "git pull" and "git pull --tags"? Same situation?

A: 

I'm going to answer this myself.

I've determined that there is a difference. "git fetch --tags" might bring in all the tags, but it doesn't bring in any new commits!

Turns out one has to do this to be totally "up to date", i.e. replicated a "git pull" without the merge:

$ git fetch --tags
$ git fetch

This is a shame, because it's twice as slow. If only "git fetch" had an option to do what it normally does and bring in all the tags.

meowsqueak
Interesting, I did not experienced that (probably because my repo was up to date at the time of my test.) +1
VonC
How about a '`git remote update myRemoteRepo`': would that fetch remote content *and* tags?
VonC
git fetch --tags will bring in all commits needed to support tags on the remote repository, but it doesn't fetch commits on branches that aren't included in the set of tags on the remote repository.
Charles Bailey
I do `git fetch` all the time and it consistently pulls down any new commits __and__ any new tags. What version of Git are you running?
Tim Visher
That's not quite what I said - I said that "git fetch --tags" does not pull down new commits. It is not a super-set of "git fetch", which does pull down new commits. So if you want the behaviour of 'git fetch' **and** the behaviour of 'git fetch --tags', you have to run both of them.I'll look into 'git remote update myRemote'.
meowsqueak
meowsqueak
A: 

In most situations, git fetch should do what you want, which is 'get anything new from the remote repository and put it in your local copy without merging to your local branches'. git fetch --tags does exactly that, except that it doesn't get anything except new tags.

In that sense, git fetch --tags is in no way a superset of git fetch. It is in fact exactly the opposite.

git pull, of course, is nothing but a wrapper for a git fetch <thisrefspec>; git merge. It's recommended that you get used to doing manual git fetching and git mergeing before you make the jump to git pull simply because it helps you understand what git pull is doing in the first place.

That being said, the relationship is exactly the same as with git fetch. git pull is the superset of git pull --tags.

Tim Visher
"git pull is the superset of git pull --tags" - but... 'git fetch' is **not** the superset of 'git fetch --tags' so the relationship isn't exactly the same...?
meowsqueak
Just found this question... well, it seems to me that `git pull` does *not* get *all* tags but only those reachable from the current branch heads. However, `git pull --tags` fetches all tags and is apparently equivalent to `git fetch --tags`.
Archimedix
+1  A: 

Most of this has been said in the other answers and comments, but here's a concise explanation:

  • git fetch fetches all branch heads (or all specified by the remote.fetch config option), all commits necessary for them, and all tags which are reachable from these branches. In most cases, all tags are reachable in this way.
  • git fetch --tags fetches all tags, all commits necessary for them. It will not update branch heads, even if they are reachable from the tags which were fetched.

Summary: If you really want to be totally up to date, using only fetch, you must do both. remote update will take care of it for you, though.

It's also not "twice as slow" unless you mean in terms of typing on the command-line, in which case aliases or remote update solve your problem. There is essentially no overhead in making the two requests, since they are asking for different information.

Jefromi
Thanks for your comment.I'm running git in Cygwin over a high-latency network - it's twice as slow when there's nothing to fetch for either (about 5 seconds).
meowsqueak
Oh, wow. Does git-remote work any better? Looking at the source briefly I think it may make only a single call - but I'm not totally sure if it'll grab the not-on-branch tags. Honestly I don't know if I've ever seen any tags not on a branch. With the things I pull from, the only way that'd happen if I waited so long that I missed a maintenance release, a feature release, and discontinuation of maintenance of the old release.
Jefromi
I think the issue is that 'git fetch' only fetches tags on **tracked** branches. We have a script that allows users to select a working branch, so by default there are many branches that are not currently tracked by an individual.
meowsqueak
I haven't tried git-remote yet, but it's on my ever-growing to-do list :)
meowsqueak
Edited to reflect the tracked branches only part. My mistake there - another default I don't mess with much.
Jefromi