git merge 冲突 : which commit was the common ancestor?

Question

我想知道在 git merge 冲突解决期间“共同祖先”提交的身份。
换种说法:我想知道 修订版的哈希值，当我在 git merge 期间解决冲突时，BASE 版本是从 中提取的。
希望有一个命令可以告诉我这些信息？
为什么我想知道

我(不幸的是)正在做一个非常复杂的 merge ，有很多冲突。

我希望能够将两个更改路径( BASE -> LOCAL 和 BASE -> REMOTE )可视化，以便让我了解更多关于这两组更改是如何发生的、是谁制作的、何时、在哪些分支上等的背景信息...

有用的 (?) 相关信息

回想一下，对于任何特定的冲突文件，都有

BASE 版本( git show :1:<path> )，来自共同祖先提交(其身份是我问题的答案)

LOCAL(我所在的分支:git show :2:<path>)版本和

REMOTE(我要 merge 的分支:git show :3:<path>)版本

我知道我可以通过使用 git ls-files -u 获得 BASE 文件本身的 SHA 哈希值，它给出的输出如下

$ git ls-files -u | grep "<path>"
100644 <SHA of BASE file> 1 <path>
100644 <SHA of LOCAL file> 2 <path>
100644 <SHA of REMOTE file> 3 <path>

我正在使用 git mergetool 和 gvimdiff3 查看冲突。此工具显示每个冲突文件(带有 "<<<" 、 ">>>" 、 "|||" 冲突标记，以及其他三个文件供引用:LOCAL、BASE 和 REMOTE。一切都非常好。

我的 BASE 文件有时会在其中包含冲突标记 (!)，如下所示:

<<<<<<<<< Temporary merge branch 1
<snip>
||||||||| merged common ancestors
=========
<snip>
>>>>>>>>> Temporary merge branch 2

我(我认为)使用 recursive merge strategy ，它声称:

When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge.

我想我看到的是“共同祖先”是几个提交的 merge 混合体。尽管如此，那个 merge 的混合体必须以某种方式生成，必须具有 SHA，并且必须具有我想知道其身份的 parent 。

Answer 1

这个很棘手，有点讨厌。你在这里完全正确:

I guess what I am seeing is that the "common ancestor" is a merged hybrid of several commits. Nevertheless, that merged hybrid must have been generated somehow, must have a SHA, and must have parents whose identities I want to know.

如 LeGEC said ，你确实有 HEAD和 MERGE_HEAD当 Git 因此 merge 冲突而停止时可用。
您可以通过以下方式找到 merge 基(复数)的哈希 ID:

git merge-base --all HEAD MERGE_HEAD

由于您使用的是 merge 递归，因此 Git 所做的是:

选择两个 merge 基础。

运行 git merge-recursive在他们。 (这本身可能会找到两个以上的 merge 基；如果是，请参阅此过程。)

提交结果。这是目前的 merge 基础。 (这个提交有一个哈希 ID。)

如果有两个以上的碱基，则选择下一个 merge 基，并将其与 merge 基到目前为止 merge ；这是现在新的 merge 基础。

重复直到所有的 merge 基都用完。

此过程的最终输出是提交哈希 ID。此哈希 ID 不会保存或显示在任何地方。您可以从 git merge-base --all 获取此过程的所有输入。当然。
通常，当 merge 发生冲突时，Git 会停止并让您修复它们。但是当 merge merge 基产生冲突时，Git 会继续并提交冲突的 merge 基。这是不好的。 (我并不是说它在这里不好，只是说它不好:它变得非常困惑。我认为，新的 merge-ort 不会这样做，但我还没有完全消化它的作用。)这些冲突标记确实是你所看到的。
Git 在这里拥有的工具不能胜任这项工作，但使用 git merge-base --all ，您至少可以检查每个输入。