【问题标题】:Creating a duplicate git commit创建一个重复的 git commit
【发布时间】:2017-01-31 15:21:07
【问题描述】:

我想知道是否可以使用相同的哈希创建两个提交。

假设我在master 分支上,我创建了一个名为foo 的新分支。现在假设我有两个终端会话,它们都被授权为作者john.smith@gmail.com。现在假设一个终端会话在master 上,另一个终端会话在foo 上,并且两个分支都具有完全相同的分阶段更改。现在假设我在两个终端会话中同时运行 git commit 命令...

这两个提交最终不会有相同的哈希值吗?

【问题讨论】:

  • @Slava.K 完全不同,我的问题不是关于 git 将如何处理这种情况,我的问题是关于你是否真的可以创造这种情况。
  • 另见stackoverflow.com/questions/25128077/… - 在脚注1中我给出了一个计算“非强制”碰撞概率的公式。如果您可以破坏或部分破坏 SHA-1,则可以增加发生冲突的概率。但是,即使您对通用 SHA-1 有已知的第二次原像攻击,您也可能需要对其进行修改以使用 Git。

标签: git


【解决方案1】:

是的,理论上你有可能遇到这种情况。提交哈希是根据提交对象的内容生成的,分别是:

  • 提交信息
  • 作者姓名
  • 创作时间戳
  • 提交者名称
  • 提交时间戳
  • 父提交列表
  • 树对象引用

树对象引用本身就是一个对象哈希,由对 blob 对象和子树的引用组成。因此,对于相同的文件树,它将是相同的。

因此,如果提交的所有这些属性都相同,那么是的,您最终会得到相同的哈希值。如果您使用相同的作者并同时提交,这绝对可以构建;由于时间戳的分辨率只有几秒钟,你甚至不需要那么精确。

但这在实践中是个问题吗?不是真的:您通常不会同时与同一个用户提交;取而代之的是,您将拥有具有自己身份的单独贡献者在自己的东西上工作。所以提交获得相同哈希的概率接近于零。

但即使这种情况发生在实践中。会不会有问题?不,提交的定义(和构造)是相同的。所以他们是一样的。而且它们彼此兼容,因此当您稍后推送或拉取时,它看起来就像您已经进行了该提交,但什么也没发生。

当然,由于SHA1的hash空间有限,还存在hash冲突的问题。在非常大的存储库中,这可能成为一个可能的问题,但我还没有听说它发生过——尽管已经有巨大的存储库。但即使它发生在其中一个上,也不会影响其他更易于管理的存储库。

【讨论】:

  • 谢谢,这是一个措辞恰当的答案 - 很容易理解。我从来没有意识到即使它确实发生了也不是问题!
猜你喜欢
  • 2012-02-24
  • 2017-04-11
  • 2023-03-08
  • 2018-07-23
  • 2017-05-11
  • 2021-09-25
  • 1970-01-01
  • 2013-03-22
  • 1970-01-01
相关资源
最近更新 更多