10

一般问题：给定一组提交，我如何找到所有这些提交作为祖先的提交列表，或者相关地，包含所有这些提交的第一个提交。

git branch --contains <commit>我可以通过查找集合中所有提交返回的分支来找到包含提交的分支（类似标签） ，但git rev-list没有--contains选项。实际上，我正在寻找一种将常规--contains参数与结合的方法，git rev-list并将输出限制为包含所有列出的提交的提交，而不是其中的任何一个（这是--contains正常工作的方式）。

具体示例：给定 commits a, b, c，我如何找到第一个在其祖先中包含所有三个提交的提交？

例如，给定下面的树，我如何找到标记为 X 的提交？

* (master)
|
X
|\
a *
| |
b c
|/
*
|
*

我认为我可以用 做一些魔法git rev-list，并且可能涉及<commit1>...<commit2>符号，但我无法进一步解决。

4

3 回答 3

2

我想这个问题的答案是 git 不是为此而生的。Git 真的不喜欢“提交的子节点”的想法，这是有充分理由的：它的定义不是很好。因为提交不知道它的子节点，所以它是一个非常模糊的集合。您可能实际上并没有在您的 repo 中拥有所有分支，因此缺少一些孩子。

Gits 的内部存储结构也使得查找提交的子节点成为一项相当昂贵的操作，因为您必须将所有头的修订图遍历到它们相应的根，或者直到您看到所有您想知道其子节点的提交。

git 支持的唯一这种概念是一个提交包含另一个提交的想法。但是只有极少数 git 命令（git branch其中之一）支持此功能。在 git 支持的地方，它不支持任意提交，只支持分支头。

这一切似乎是 git 的一个相当严格的限制，但在实践中，您不需要提交的“孩子”，而通常只需要知道哪些分支包含特定的提交。

这就是说：如果您真的想得到问题的答案，您将不得不编写自己的脚本来找到它。最简单的方法是从git rev-list --parents --reverse --all. 逐行解析，您将构建一棵树，并为每个节点标记它是否是您正在寻找的提交的子节点。您可以通过在遇到提交后自己标记提交，然后将该属性传递给他们的所有孩子等等来做到这一点。

一旦你有一个标记为包含所有提交的提交，你就将它添加到你的“解决方案列表”中并将它的所有子节点标记为死——它们不能再包含任何第一个提交。然后，此属性也将传递给它的所有后代。

如果您不存储不包含您要求的任何提交的树的任何部分，则可以在此处节省一些内存。

编辑破解了一些python代码

#!/usr/bin/python -O
import os
import sys

if len(sys.argv) < 2:
    print ("USAGE: {0} <list-of-revs>".format([sys.argv[0]]))
    exit(1)

rev_list = os.popen('git rev-list --parents --reverse --all')

looking_for = os.popen('git rev-parse {0}'
                       .format(" ".join(sys.argv[1:]))).read().splitlines()
solutions = set()
commits = {}

for line in rev_list:
    line = line.strip().split(" ")
    commit = set()
    sha = line[0]
    for parent in line[1:]:
        if not parent in commits:
            continue
        commit.update(commits[parent])
        if parent in solutions:
            commit.add("dead")
    if sha in looking_for:
        commit.add(sha)
    if not "dead" in commit and commit.issuperset(looking_for):
        solutions.add(sha)
    # only keep commit if it's a child of looking_for
    if len(commit) > 0:
        commits[sha] = commit

print "\n".join(solutions)
于 2012-12-20T12:15:00.587 回答
1

一种可能的解决方案：

使用 'git merge-base ab c' 获取提交以用作调用 rev-list 的起点；我们称之为$MERGE_BASE。

使用 'git rev-list $MERGE_BASE..HEAD' 调用列出从它们的共同祖先到 HEAD 的所有提交。循环通过此输出（伪代码）：

if commit == a || b || c
  break
else 
  $OLDEST_DESCENDANT = commit
return $OLDEST_DESCENDANT

这将适用于您上面的示例，但如果它们从未被合并，没有在最年轻的 a、b、c 之后的提交中立即合并，或者如果有多个合并提交将 a 组合在一起，则会给出误报， b 和 c（如果它们各自驻留在自己的分支上）。要找到最古老的后代，还有一些工作要做。

然后，您应该按照上面的内容，以 $OLDEST_DESCENDANT 开头，然后在 DAG 中从它向 HEAD （rev-list --reverse $OLDEST_DESCENDANT~..HEAD）逆向前进，测试以查看 'rev-list $MERGE_BASE 的输出~..$OLDEST 包含所有需要的提交 a、b 和 c（不过，也许有比 rev-list 更好的方法来测试它们是否可访问）。

正如 twalberg 所提到的，像这样单独测试提交似乎不是最佳且缓慢的，但这是一个开始。这种方法比他的合并提交列表方法的优势在于，当所有输入提交都在同一个分支上时，它将提供有效的响应。

性能主要受合并基础、头部、X 和所需提交集（a、b 和 c）中最年轻的之间的距离的影响。

于 2012-12-19T01:33:33.067 回答
-1

怎么样 ：

MERGE_BASE=`git merge-base A B C`
git log $MERGE_BASE...HEAD --merges

假设您只有 1 个合并。即使您有更多合并，最旧的合并也是包含所有三个提交的更改的合并

于 2012-12-19T16:35:58.777 回答