git - 你能以任何方式在 Git 中获得重复的哈希值吗？这意味着什么

Question

我的观点是应该有可能得到一个重复的 git 散列，因为散列码是唯一性的浓缩表示，因此会有一些步骤序列产生相同的散列码。更重要的是，应该有一系列步骤，其中提交不同的更改但会产生相同的哈希码。

例如，在同一台机器上克隆同一个存储库两次，在不同的存储库中进行几乎完全相同的更改(保存一个字节或一位)并提交。即使在提交中使用了目录名称或时间戳，仍然应该可以获得它(尽管很少见)。例如，两个不同的人在两台不同的机器上同时进行提交。

我的问题有两个方面。这怎么会发生以及 Git 将如何处理它。

或者更明确地说，git 如何确保您在推送之前是最新的。是否有可能一个人先推送，然后另一个人尝试推送(两个更改都基于同一个父提交)并且 Git 看到哈希码与远程和本地历史匹配，决定你可以继续，允许你推但你刚刚丢失了一个更改？在这种情况下，我更像是这样:

repo 1a->b->c1

repo 协议(protocol)2a->b->c1'->c2

假设 c1、c1'、c2 都发生在两个 repos 都被克隆到 b 之后，现在 repo1 推送，没问题现在 repo2 尝试推送 c1' 和 c2 并且 git 确定 c1' = c1 但实际上它们不同，git 将 c2 推送到 c1 之上以获得a->b->c1->c2我们丢失了在 c1 中所做的更改'

这可能吗？它怎么会发生，git 会做什么？

Answer 1

关于您的问题中与重复哈希相关的部分:

Git 完全依赖于生成的哈希值的唯一性，据我所知，它没有任何安全措施来处理产生相同哈希值的不同数据 block 。然而，发生散列冲突的可能性微乎其微，实际上可以忽略不计。如果你还担心，this section from Pro Git可以让您安心:

A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.

至于你问题的第二部分(会发生什么):

If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object.