git tag --contains如何工作? [英] How does git tag --contains work?
问题描述
自几天前以来,我一直在尝试确定在哪个版本中(由标签指定)-特定修复程序(由提交指定)进行了部署.这里的一些帖子指出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:
- 提交32c35cf (2009年1月26日,git 1.6.0-rc2),由杰克·古丁(
shepmaster
).
(由 Junio C Hamano合并-gitster
-,2009年1月28日) - 提交ffc4b80 (2011年6月11日,git 1.7.6.3)通过杰夫·金(
peff
).
(由 Junio C Hamano合并-gitster
-,2011年6月12日)
- 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
(或一组提交中的任何一个,从B
到Z
)时,我们通常计算合并基数,然后查看B
是否为 A 的合并基础(或对于一个集合,如果B
至Z
中的任何提交都具有该属性).
speed up
--contains
calculationWhen we want to know if commit
A
contains commitB
(or any one of a set of commits,B
throughZ
), we generally calculate the merge bases and see ifB
is a merge base of A (or for a set, if any of the commitsB
throughZ
have that property).
当我们要检查一系列提交A1
至An
以查看每个提交是否都包含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 overflowIn 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屋!