“ git fetch --tags”是否包括“ git fetch”？
一个不错的简单问题-“ git fetch”的函数是否是的严格子集git fetch --tags？
即是说，如果我跑步git fetch --tags，是否有理由立即直接跑步git fetch？
怎么样git pull和git pull --tags？同样的情况？
呼唤远方浏览 1746回答 3
3回答
-
慕田峪7331174
注意：从git 1.9 / 2.0（Q1 2014）开始，除了在同一命令行中不带选项的情况下，还将git fetch --tags获取标签。见提交c5a84e9由迈克尔·哈格蒂（mhagger） ：以前，fetch的“ --tags”选项被认为等同于指定refspecrefs/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日）pyokagangitsterpull：--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日）peffgitsterfetch：使用“快速” 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 allowedGit 2.24（2019年第四季度）增加了另一个优化。请参阅Masaya Suzuki（）的commit b7e2d8b（2019年9月15日）。（由Junio C Hamano合并--在commit 1d8b0df中，2019年10月7日）draftcodegitsterfetch：用于oidset保留想要的OID以便更快地查找在期间git fetch，客户端检查广告标记的OID是否已经在获取请求的OID集中。该检查是在线性扫描中完成的。对于具有大量引用的存储库，重复此扫描需要15分钟以上。为了加快速度，请oid_set为其他裁判的OID 创建一个。 -
慕勒3428872
注意：此答案仅对git v1.8及更早版本有效。在其他答案和评论中已经说了大部分，但这是一个简洁的解释：git fetch获取所有分支头（或所有由remote.fetch config选项指定的分支头），它们所需的所有提交以及从这些分支可访问的所有标记。在大多数情况下，所有标签都可以通过这种方式访问。git fetch --tags获取所有标签，并完成所有必需的提交。即使从提取的标签可以到达分支头，它也不会更新。简介：如果您真的想完全保持最新，仅使用访存，则必须同时进行。除非您是在命令行中输入，否则它也不会“慢两倍”，在这种情况下，别名可以解决您的问题。发出两个请求基本上没有开销，因为它们要求的是不同的信息。 -
qq_笑_17
我将自己回答。我确定有区别。“ git fetch --tags”可能会引入所有标签，但不会带来任何新的提交！事实证明，这样做必须完全“最新”，即在没有合并的情况下复制了“ git pull”：$ git fetch --tags$ git fetch真可惜，因为速度慢了两倍。如果只有“ git fetch”可以选择执行其通常的操作并引入所有标签
随时随地看视频慕课网APP
Git