git - "git fetch --tags"是否包括 "git fetch"？

Question

一个很好的简单问题 - “git fetch”的函数是 git fetch --tags 的严格子集吗？

即如果我运行 git fetch --tags，是否有理由立即运行 git fetch？

git pull 和 git pull --tags 呢？一样的情况？

Answer 1

注意:从 git 1.9/2.0 (Q1 2014) 开始，git fetch --tags 获取标签除了在没有选项的情况下通过同一命令行获取的内容。

只获取标签:

git fetch <remote> 'refs/tags/*:refs/tags/*'

详细信息:

参见 commit c5a84e9 的 Michael Haggerty (mhagger) :

Previously, fetch's "--tags" option was considered equivalent to specifying the refspec

refs/tags/*:refs/tags/*

on the command line;in particular, it caused the remote.<name>.refspec configuration 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 1.8.0.3 was ambiguous about this aspect of "fetch --tags" behavior.
Commit f0cb2f1 (2012-12-14) fetch --tags made the documentation match the old behavior.
This commit changes the documentation to match the new behavior (see Documentation/fetch-options.txt).

Request that all tags be fetched from the remote in addition to whatever else is being fetched.

---

自 Git 2.5(2015 年第 2 季度)起，git pull --tags 更加健壮:

参见 commit 19d122b 的 Paul Tan ( pyokagan )，2015 年 5 月 13 日。
^{(由 Junio C Hamano -- gitster -- merge 于 commit cc77b99 ，2015 年 5 月 22 日)}

pull: remove --tags error 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 --tags would print a different error message ifgit-fetch did 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 --tags would override anyconfigured 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 toother stuff, 2013-10-30, Git 1.9.0+), git fetch --tags would fetch tags in additionto any configured refspecs.
Hence, if any no merge candidates situation occurs, it is not because --tags was set. As such, this special error message is now irrelevant.

To prevent confusion, remove this error message.

---

使用 Git 2.11+(2016 年第 4 季度)git fetch 更快。

参见 commit 5827a03 的 Jeff King ( peff )(2016 年 10 月 13 日)。
^{(由 Junio C Hamano -- gitster -- merge 到 commit 9fcd144 ，2016 年 10 月 26 日)}

fetch: use "quick" has_sha1_file for 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 sacrificeaccuracy for speed, in cases where we might be racy with asimultaneous repack.

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%

这仅适用于以下情况:

1. 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).
2. 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.
3. 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(2019 年 2 月)似乎在 config remote.origin.fetch is not the default one ( '+refs/heads/*:refs/remotes/origin/*' ) 时引入了回归

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

---

Git 2.24(2019 年第 4 季度)增加了另一项优化。

参见 commit b7e2d8b 的 Masaya Suzuki ( draftcode )(2019 年 9 月 15 日)。
^{(由 Junio C Hamano -- gitster -- merge 到 commit 1d8b0df ，2019 年 10 月 7 日)}

fetch: use oidset to keep the want OIDs for faster lookup

During 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_set for other refs' OIDs.