是否有可能构建一个循环git历史，如下面的ascii-art？
A (root)
| H<-G
| / \
VL \
C F
\ /
\ /
D->E
其中C是A和H的合并提交，但H本身是C
答案 0 :(得分：5)
每个提交ID都是包含其直接祖先的提交ID的SHA-1哈希，因此通常您需要知道祖先的ID才能找到可以作为其后代的ID。因此，没有地方可以开始构建一个循环。
能够构造一个短循环结构（其中“short”意味着在循环中少于2 ^ 64次提交）将构成正在使用的散列函数的中断。
已知SHA-1在碰撞阻力方面被打破，并且可以想象这个突破背后的技术可以适应构建一个循环。但目前尚不清楚如何做到这一点，当然不仅仅是将一些现成的密码分析组件插入到一起。
答案 1 :(得分：2)
正如Henning Makholm所指出的那样，提交包括其父代的SHA1哈希码，并且已知有两种具有相同SHA1哈希值的文档的技术，这些哈希只需要多个高端CPU时间才能工作。
没有考虑到的是这些技术取决于受控文档修改：给定两个当前文档（带有特定的哈希码），您可以计算修改，使得生成的哈希码对“更接近”通过一些指标相互对立。但是，从Finding Collisions in the Full SHA-1开始，“请注意，消息修改应该保留所有消息条件”。
这意味着计算那些特定文档中的特定位修改，并且您无法使用git提交，因为任何修改也会随机化160个其他位。没有对相互依赖的git提交哈希值进行可预测的修改，而且已知的技术几乎无法脱离启动门。
即便如此，也没有描述你要求的具体任务是多么冒险：它不是搜索具有相同哈希码的两个文档，而是搜索两个文档，每个文档包含另一个哈希代码，（如果你设法使它们相同，也可以是他们自己的代码）在特定的地方。据我所知，目前还没有关于这个问题的研究。
所以我认为真正的答案是“没有人曾经尝试过，更不用说如何通过任何不太可能的机会来实现这一点”。
答案 2 :(得分：0)
不。
Git形成有向无环图，因此您无法进行循环。