是否“git fetch --tags”包括“git fetch”？ [英] Does "git fetch --tags" include "git fetch"?

问题描述

一个很好又简单的问题 - 是git fetch的一个严格的子集 --tags ？

即，如果我运行 git fetch --tags ，是否曾有理由立即直接运行 git fetch ？ p>

那么 git pull 和 git pull --tags ？同样的情况？

解决方案

注意：从 git 1.9 / 2.0（Q1 2014）， git fetch --tags fetches tags 除了之外，没有选项的同一命令行提取的内容。 commit c5a84e9 通过 Michael Haggerty（mhagger）：

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

  refs / tags / *：refs / tags / * 
  

在命令行上;特别是
，导致远程。< 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（Q2 2015） git pull --tags 更强大：

请参阅 Paul Tan（ pyokagan ），13提交19d122b 2015年5月。

^{（由 Junio C Hamano - gitster - 在提交cc77b99 ，2015年5月22日）}

拉：删除 - 标记错误在没有合并的候选人的情况下

由于 441ed41 （ git pull --tags ：出错信息更好。，
2007-12-28，Git 1.5.4+），如果
git-fetch 没有返回任何合并候选：> git pull --tags 会输出不同的错误信息：

 拉出所有标签没有意​​义;你可能意思是：
 git fetch --tags 
  

这是因为当时 git-fetch -tags 会覆盖任何
配置的refspecs，因此不会有合并候选项。因此引入了错误消息以防止混淆。

但是，由于 c5a84e9 （ fetch --tags ：fetch tags 除了
其他的东西，2013-10-30，Git 1.9.0+）， git fetch --tags 会将标记另外
附加到任何已配置的refspecs中。

因此，如果有合并候选人的情况发生，这不是因为设置了 - tags 。因此，现在这个特殊的错误信息是无关紧要的。

为了防止混淆，请删除此错误消息。





---

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

请参阅提交5827a03 （2016年10月13日）Jeff King（ peff ）。

^{（由 Junio C Hamano - gitster - 位于 commit 9fcd144 ，2016年10月26日）}
$ b

fetch ：使用quick has_sha1_file 用于标记跟踪

从具有多个不相关标记的远程获取对于我们所关注的分支，我们过去在检查标签指向的对象（我们不会去获取！）时会浪费太多的时间周期。

这个补丁教导提取使用HAS_SHA1_QUICK以牺牲
的速度准确性，以防我们可能在同时进行
同时重新打包时遇到问题。

以下是包含的perf脚本的结果，其中包含类似于上面描述的情况：

 测试头部^头部
 ---------------------------------- ------------------------ 
 5550.4：取11.21（10.42 + 0.78）0.08（0.04 + 0.02）-99.3％
  

仅适用于以下情况：



1. 客户端上有很多包使得 reprepare_packed_git（）非常昂贵（最昂贵的部分是在一个unsorte d列表，它当前是二次的）。


2. 在服务器端需要大量的标签引用，这些标签引用是自动跟踪的候选对象（即客户端没有的） 。
   每一个都会触发对包目录的重新读取。


3. 在正常情况下，客户端会自动跟踪这些标签，并且在一次大提取后，（2）不会如果这些标签指向的历史与客户端以其他方式获取的历史记录断开连接，那么它将永远不会自动跟踪，而这些候选项将在每次获取时影响它。




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?

解决方案

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.

See commit c5a84e9 by 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.

---

Since Git 2.5 (Q2 2015) git pull --tags is more robust:

See commit 19d122b by Paul Tan (pyokagan), 13 May 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit cc77b99, 22 May 2015)}

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 if git-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 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 --tags would fetch tags in addition to 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.

---

With Git 2.11+ (Q4 2016) git fetch is quicker.

See commit 5827a03 (13 Oct 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 9fcd144, 26 Oct 2016)}

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 sacrifice accuracy for speed, in cases where we might be racy with a simultaneous 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%

That applies only for a situation where:

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 fetch --tags”包括“git fetch”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！