“ 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获取标签。

见提交c5a84e9由迈克尔·哈格蒂（mhagger） ：

以前，fetch的“ --tags”选项被认为等同于指定refspec

refs/tags/*:refs/tags/*

在命令行上；特别是，它导致该remote.<name>.refspec配置被忽略。

但它并非没有取也是其他参考获取标签是非常有用的，而它是能够抓取代码非常有用，除了其他的引用。

因此，请更改此选项的语义以执行后者。

如果用户想要获取唯一的标签，那么它仍然可以指定一个明确的Refspec：

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

请注意，1.8.0.3之前的文档在fetch --tags行为方面没有明确规定。

提交f0cb2f1（2012-12-14）fetch --tags使文档与旧行为匹配。

此提交更改了文档以匹配新行为（请参阅参考资料Documentation/fetch-options.txt）。

要求除了获取其他内容外，还从远程获取所有标签。

由于Git 2.5（2015年第二季度）git pull --tags更强大：

参见Paul Tan（）提交的commit 19d122b，2015年5月13日。（由Junio C Hamano合并--在cc77b99提交中，2015年5月22日）pyokagan

gitster

pull：--tags在没有合并候选者的情况下删除错误

自441ed41（“ git pull --tags”：出现错误时，出现了一条更好的消息。，2007-12-28，Git 1.5.4+），git pull --tags如果git-fetch未返回任何合并候选者，则会打印出另一条错误消息 ：

It doesn't make sense to pull all tags; you probably meant:

       git fetch --tags

这是因为那时git-fetch --tags将覆盖所有已配置的refspec，因此将没有合并候选者。因此引入了错误消息以防止混淆。

但是，由于c5a84e9（fetch --tags：除了 其他内容外，还可以获取标签，2013-10-30，Git 1.9.0+），git fetch --tags可以获取任何已配置的refspec 之外的标签。

因此，如果没有任何合并候选者的情况发生，那不是因为--tags被设置。因此，此特殊错误消息现在不相关。

为避免混淆，请删除此错误消息。

使用Git 2.11+（2016年第四季度）git fetch更快。

参见Jeff King（）提交5827a03（2016年10月13日）。（由Junio C Hamano合并--在commit 9fcd144中，2016年10月26日）peff

gitster

fetch：使用“快速” has_sha1_file进行标记跟踪

当从具有很多与分支无关的标签的远程进行提取时，我们通常会在检查存储库中是否存在由标签指向的对象（我们不会提取！）时浪费了太多的时间。太小心了

此修补程序告诉fetch使用HAS_SHA1_QUICK牺牲准确性以提高速度，以防我们可能因同时重新打包而感到厌倦。

以下是所包含的perf脚本的结果，该脚本设置了与上述情况类似的情况：

Test            HEAD^               HEAD

----------------------------------------------------------

5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

这仅适用于以下情况：

您在客户端有很多包装，reprepare_packed_git()价格昂贵（最昂贵的部分是在未排序的列表中查找重复项，该列表目前是二次的）。

您需要在服务器端有大量的标记引用，这些标记引用可以自动跟踪（即客户端没有）。每一个都会触发对pack目录的重新读取。

在正常情况下，客户端会自动关注这些标签，并且在进行一次大抓取后，（2）将不再为真。

但是，如果这些标记指向的历史与客户端获取的内容断开连接，那么它将永远不会自动关注，并且这些候选对象将在每次获取时对其进行影响。

Git的2.21（2019年2月）似乎已经引入了回归时的配置remote.origin.fetch是不是默认的（'+refs/heads/*:refs/remotes/origin/*'）

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

Git 2.24（2019年第四季度）增加了另一个优化。

请参阅Masaya Suzuki（）的commit b7e2d8b（2019年9月15日）。（由Junio C Hamano合并--在commit 1d8b0df中，2019年10月7日）draftcode

gitster

fetch：用于oidset保留想要的OID以便更快地查找

在期间git fetch，客户端检查广告标记的OID是否已经在获取请求的OID集中。

该检查是在线性扫描中完成的。

对于具有大量引用的存储库，重复此扫描需要15分钟以上。

为了加快速度，请oid_set为其他裁判的OID 创建一个。

Answer 2

注意：此答案仅对git v1.8及更早版本有效。

在其他答案和评论中已经说了大部分，但这是一个简洁的解释：

• git fetch获取所有分支头（或所有由remote.fetch config选项指定的分支头），它们所需的所有提交以及从这些分支可访问的所有标记。在大多数情况下，所有标签都可以通过这种方式访问。

• git fetch --tags获取所有标签，并完成所有必需的提交。即使从提取的标签可以到达分支头，它也不会更新。

简介：如果您真的想完全保持最新，仅使用访存，则必须同时进行。

除非您是在命令行中输入，否则它也不会“慢两倍”，在这种情况下，别名可以解决您的问题。发出两个请求基本上没有开销，因为它们要求的是不同的信息。

Answer 3

我将自己回答。

我确定有区别。“ git fetch --tags”可能会引入所有标签，但不会带来任何新的提交！

事实证明，这样做必须完全“最新”，即在没有合并的情况下复制了“ git pull”：

$ git fetch --tags

$ git fetch

真可惜，因为速度慢了两倍。如果只有“ git fetch”可以选择执行其通常的操作并引入所有标签