5

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

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

我的问题是两方面的。这怎么会发生，Git 将如何处理它。

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

repo1 a->b->c1

repo2 a->b->c1'->c2

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

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

4

1 回答 1

12

关于与重复哈希有关的问题部分：

Git 完全依赖于生成的哈希值的唯一性，据我所知，它没有任何安全措施来处理产生相同哈希值的不同数据块。但是，发生哈希冲突的机会非常小，实际上可以忽略不计。如果您仍然担心，Pro Git 的这一部分可能会让您放心：

您的编程团队的每个成员都更有可能在同一晚在不相关的事件中被狼袭击和杀死。

至于你问题的第二部分（会发生什么）：

如果您碰巧提交了一个对象，该对象的哈希值与您的存储库中的前一个对象相同，Git 将在您的 Git 数据库中看到前一个对象并假设它已经被写入。如果您尝试在某个时候再次检查该对象，您将始终获得第一个对象的数据。

于 2012-08-02T12:16:06.547 回答