git tag --contains如何工作? [英] How does git tag --contains work?

查看:456
本文介绍了git tag --contains如何工作?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

自几天前以来,我一直在尝试确定在哪个版本中(由标签指定)-特定修复程序(由提交指定)进行了部署.这里的一些帖子指出git tag --contains是收集此信息的方法,但是该选项的文档对我来说似乎很晦涩:

Since a few days ago I've being trying to identify in which release -specified by a tag- an specific fix -specified by a commit- was deployed. Some posts here posted that git tag --contains is the way to gather this information, however the documentation of the option seems obscure to me:

-包含[commit]: 仅列出包含指定提交的标签(如果未指定,则为HEAD).

--contains [commit]: Only list tags which contain the specified commit (HEAD if not specified).

到目前为止,我一直在阅读git中的标记只是指向特定提交的指针,因此尚不清楚提交引用如何包含"另一个提交引用.您知道git tag --contains如何获取其产生的信息吗?

From what I've being reading so far, a tag in git is just a pointer to a specific commit, so it is not clear how a commit reference can "contain" another commit reference. Do you know how git tag --contains obtains the information it produces?

推荐答案

因此,尚不清楚提交引用如何包含"另一个提交引用

so it is not clear how a commit reference can "contain" another commit reference

您可以在git中引入/增强了此功能的提交中看到更多信息.
参见:

You can see more in the commit which introduced/enhanced this feature in git.
See:

  • commit 32c35cf (26 Jan 2009, git 1.6.0-rc2) by Jake Goulding (shepmaster).
    (Merged by Junio C Hamano -- gitster --, 28 Jan 2009)
  • commit ffc4b80 (11 Jun 2011, git 1.7.6.3) by Jeff King (peff).
    (Merged by Junio C Hamano -- gitster --, 12 Jun 2011)

这最初是通过 git merge-base 完成的,但是:

This was initially done through git merge-base, but:

加快--contains计算

当我们想知道提交A是否包含提交B(或一组提交中的任何一个,从BZ)时,我们通常计算合并基数,然后查看B是否为 A 的合并基础(或对于一个集合,如果BZ中的任何提交都具有该属性).

speed up --contains calculation

When we want to know if commit A contains commit B (or any one of a set of commits, B through Z), we generally calculate the merge bases and see if B is a merge base of A (or for a set, if any of the commits B through Z have that property).

当我们要检查一系列提交A1An以查看每个提交是否都包含B时(例如,因为我们正在决定要使用"git tag --contains"显示的标签),我们将执行系列合并基础计算.这很昂贵,因为我们要重复很多遍历工作.

When we are going to check a series of commits A1 through An to see whether each contains B (e.g., because we are deciding which tags to show with "git tag --contains"), we do a series of merge base calculations. This can be very expensive, as we repeat a lot of traversal work.

相反,让我们利用以下事实:我们将对每个标签使用相同的--contains列表,并且提交图的标记区域肯定包含这些提交,或者绝对不包含那些提交.
以后的标签一旦看到先前计算出的内容,便可以立即停止遍历 答案.

Instead, let's leverage the fact that we are going to use the same --contains list for each tag, and mark areas of the commit graph is definitely containing those commits, or definitely not containing those commits.
Later tags can then stop traversing as soon as they see a previously calculated answer.

那是通过递归完成的,但是...

That was done through recursion, but...

请参见提交cbc60b6 (2014年4月24日,git 2.1.0-rc0) 让-雅克·拉斐(DontKnowPS).
(由 Junio C Hamano合并– gitster-,2014年4月25日)

See commit cbc60b6 (24 Apr 2014, git 2.1.0-rc0) by Jean-Jacques Lafay (DontKnowPS).
(Merged by Junio C Hamano -- gitster --, 25 Apr 2014)

git tag --contains:避免堆栈溢出

在大型存储库中,contains(commit, commit_list)的递归实现可能会导致堆栈溢出.用循环替换递归以对其进行修复.

git tag --contains: avoid stack overflow

In large repos, the recursion implementation of contains(commit, commit_list) may result in a stack overflow. Replace the recursion with a loop to fix it.

此问题在Windows上比在堆栈上的Linux上更为明显 默认情况下受到更多限制.另请参见 msysGit列表上的该线程.

This problem is more apparent on Windows than on Linux, where the stack is more limited by default. See also this thread on the msysGit list.

这篇关于git tag --contains如何工作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆