git - 一个提交可以是它自己在 git 中的祖先吗？

Question

是否可以像下面的 ascii-art 那样构建一个循环的 git 历史？

A (root)
|  H<-G
| /    \
VL      \
C        F
 \      /
  \    /
   D->E

和C的合并提交在哪里，但它本身是AHHC

Answer 1

每个提交 ID 都是包含其直接祖先的提交 ID 的 SHA-1 哈希，因此通常您需要知道祖先的 ID，然后才能找到可以作为其后代的 ID。因此，没有地方开始构建循环。

能够构建一个短周期结构（其中“短”意味着在周期中提交少于 2^64 次）将构成正在使用的散列函数的中断。

众所周知，SHA-1 在抗碰撞性方面被破坏，并且可以想象，这种破坏背后的技术可以适应构建循环。但目前尚不清楚如何做到这一点，而且这肯定不仅仅是将一些现成的密码分析组件塞在一起的问题。

Answer 2

正如 Henning Makholm 上面所指出的，提交包括其父级的 SHA1 哈希码，并且有已知的技术可以生成两个具有相同 SHA1 哈希值的文档，这些文档只需要多个高端 cpu 年即可工作。

没有考虑到的是，这些技术依赖于受控文档修改：给定两个当前文档（带有它们特定的哈希码），您可以计算修改，使生成的哈希码对彼此“更接近”一些指标。但是，从Find Collisions in the Full SHA-1中，“请注意，消息修改应保留所有消息条件”。

这意味着计算那些特定文档中的特定位修改，而 git 提交则无法做到这一点，因为任何修改也会随机化 160 个其他位。对相互依赖的 git 提交哈希没有可预测的修改，而已知的技术几乎都无法走出起点。

即使这并不能描述您所要求的具体任务是多么冒险：它不是搜索具有相同哈希码的两个文档，而是搜索两个文档，每个文档都包含另一个哈希码，（这也将是他们自己的，如果你设法使它们相同）在一个特定的地方。据我所知，还没有关于这个问题的研究。

因此，我认为真正的答案是“没有人曾经尝试过，更不用说最不知道如何通过任何不太可能发生的事情来实现这一点”。

Answer 3

没有。

Git 形成一个有向无环图，所以你不能有循环。