Posted By: Anonymous
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?
git pull and
git pull --tags? Same situation?
Note: starting with git 1.9/2.0 (Q1 2014),
git fetch --tags fetches tags in addition to what are fetched by the same command line without the option.
To fetch only tags:
git fetch <remote> 'refs/tags/*:refs/tags/*
Previously, fetch’s "
--tags" option was considered equivalent to specifying the refspec
on the command line;
in particular, it caused the
remote.<name>.refspecconfiguration to be ignored.
But it is not very useful to fetch tags without also fetching other references, whereas it is quite useful to be able to fetch tags in addition to other references.
So change the semantics of this option to do the latter.
If a user wants to fetch only tags, then it is still possible to specifying an explicit refspec:
git fetch <remote> 'refs/tags/*:refs/tags/*'
Please note that the documentation prior to 184.108.40.206 was ambiguous about this aspect of "
fetch --tags" behavior.
Commit f0cb2f1 (2012-12-14)
fetch --tagsmade the documentation match the old behavior.
This commit changes the documentation to match the new behavior (see
Request that all tags be fetched from the remote in addition to whatever else is being fetched.
Since Git 2.5 (Q2 2015)
git pull --tags is more robust:
--tagserror in no merge candidates case
Since 441ed41 ("
git pull --tags": error out with a better message.,
2007-12-28, Git 1.5.4+),
git pull --tagswould print a different error message if
git-fetchdid not return any merge candidates:
It doesn't make sense to pull all tags; you probably meant: git fetch --tags
This is because at that time,
git-fetch --tagswould override any
configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion.
However, since c5a84e9 (
fetch --tags: fetch tags in addition to
other stuff, 2013-10-30, Git 1.9.0+),
git fetch --tagswould fetch tags in addition
to any configured refspecs.
Hence, if any no merge candidates situation occurs, it is not because
--tagswas set. As such, this special error message is now irrelevant.
To prevent confusion, remove this error message.
With Git 2.11+ (Q4 2016)
git fetch is quicker.
fetch: use "quick"
has_sha1_filefor tag following
When fetching from a remote that has many tags that are irrelevant to branches we are following, we used to waste way too many cycles when checking if the object pointed at by a tag (that we are not going to fetch!) exists in our repository too carefully.
This patch teaches fetch to use HAS_SHA1_QUICK to sacrifice
accuracy for speed, in cases where we might be racy with a
Here are results from the included perf script, which sets up a situation similar to the one described above:
Test HEAD^ HEAD ---------------------------------------------------------- 5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3%
That applies only for a situation where:
- You have a lot of packs on the client side to make
reprepare_packed_git()expensive (the most expensive part is finding duplicates in an unsorted list, which is currently quadratic).
- You need a large number of tag refs on the server side that are candidates for auto-following (i.e., that the client doesn’t have).
Each one triggers a re-read of the pack directory.
- Under normal circumstances, the client would auto-follow those tags and after one large fetch, (2) would no longer be true.
But if those tags point to history which is disconnected from what the client otherwise fetches, then it will never auto-follow, and those candidates will impact it on every fetch.
Git 2.21 (Feb. 2019) seems to have introduced a regression when the config
remote.origin.fetch is not the default one (
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed
Git 2.24 (Q4 2019) adds another optimization.
oidsetto keep the want OIDs for faster lookup
git fetch, the client checks if the advertised tags’ OIDs are already in the fetch request’s want OID set.
This check is done in a linear scan.
For a repository that has a lot of refs, repeating this scan takes 15+ minutes.
In order to speed this up, create a
oid_setfor other refs’ OIDs.