0

--contains选项有什么作用git for-each-ref？

如果它的 revlist--contains在命令行上的选项之后指定了提交，它是否只返回一个引用？（例如，是否git for-each-ref refs/heads --contains feature/test只返回那些在其修订列表中包含提交feature/test的头部？（即它们与第一次提交之间的提交列表，即git rev-list <ref>））？

Git 文档（v. 2.31.1；见这里）实际上已经过时了：Notes底部的部分声明您可以一起使用--mergedand--no-merged选项，但这与此提交不兼容。

文档中提供的定义是模棱两可的：它重用了“包含”这个词，但没有澄清它的含义。引用是仅指向一个 SHA 的名称。“包含”的概念表明引用是指多次提交，这仅在其git rev-list.

提交可以在另一个提交之后或之前（仅通过提交时间），但如果从该提交无法访问（即，如果提交未合并到其分支中），则提交不知道它，因此它可以不要说“包含”它。

这就是为什么--mergedand --no-mergedtogether 是有意义的：它将返回可从（至少一个）到达的提交，--merged而没有一个--no-merged.

“包含”是什么意思？...“有直接父 X”？“有祖先X”？“有表弟X”吗？

更新：

看来我使用的是旧版本的 Git。在 v2.28.1 中同时使用两者--merged和--no-merged一起使用是不兼容的，但现在在 v2.31.1 中是兼容的。因此，Git 文档并没有过时。

似乎此提交是在 2017 年 3 月 21 日进行的，比 v2.31.1 早得多（不确定它到底是用哪个版本提交的）。

其次，@LeGEC 的回答似乎是有道理的（相对于--contains/的--no-contains意思是“给我在他们之后有这个提交的裁判”和--merged/--no-merged意味着“给我在他们之前有这个提交的裁判”。

不过，如果能进一步澄清 Git 文档，那就太好了。像他们所做的那样使用定义中的词是非常模糊的。

因为 Git 是一个有向无环图 (DAG)，所以提交指向一个方向的链表形式的其他提交：时间倒退到它们的祖先。因此，名称--merged/--no-merged及其在“可达性”方面的描述是有意义的。

“包含”是指“之后且可到达”（即孩子），还是简单地“之后”（即稍后做出的提交）？

由于这是一个管道命令（在自定义脚本中使用），我需要确切地知道它的作用以及它是如何工作的，这样我的脚本就不会产生任何意外的副作用。

旧 Git 版本问题

4

1 回答 1

2

也许我误解了您的问题，如果相关，请更新您的问题。

该文档给出了这些选项的正确（但可能简洁？）描述，这
是一种不同的措辞方式：

  • --merged develop意思是“先于develop”
  • --no-merged master意思是“没有出现master”
  • --contains feature1意思是“之后feature1”
  • --no-contains feature2意思是“不追随feature2”

这 4 个选项实际上是兼容的：

git for-each-ref --merged develop --no-merged master --contains feature1 --no-contains feature2

将列出以下引用：

  • 已合并develop，但master尚未合并，
  • 包含feature1（例如：以某种方式合并到它们中） ，feature1并且还不包含feature2

[更新] 一个 ref 指向一个commit，一个 commit 有指向它的parents的指针。有了这种关系，git 中的提交形成了一个图（实际上是一个 DAG）。

“合并”（或我不正确的“之前”）表示“是”的祖先，“包含”（或我不正确的“之后”）表示“是”的后代。

您提到git rev-list：如果git rev-list commitB列出 的 sha commitA，那么您可以说：

  • commitB包含commitA
  • commitA被合并到commitB
于 2021-05-11T20:34:11.813 回答