git - git 如何确保相同操作/数据的提交 SHA key 仍然是唯一的？

Question

如果我用 touch foo 创建一个文件 foo 然后运行 ​​shasum foo 它会打印出来

da39a3ee5e6b4b0d3255bfef95601890afd80709。

无论我多久运行一次 shasum foo 或者如果我在另一台计算机上运行它，它总是会打印 da39a3ee5e6b4b0d3255bfef95601890afd80709 因为，是的，它正是相同的内容。在这种情况下为空内容 :)

但是，如果我执行以下步骤:

cd /some/where
mkdir demo
git init
touch foo
git add -A
git commit -m "adding foo"

..并记住提交的 SHA key (例如 959c363ed4cf147725360532454bc258c964c744)。

现在，当我删除 demo 并重复完全相同的步骤时，commit SHA key 仍然会有所不同。这很好，确保身份很重要。

不过我想知道的是，git 究竟做了什么来确保提交哈希始终是唯一的，即使它们使用完全相同的内容执行完全相同的操作。 git 是简单地使用类似 uuidgen 的东西来为提交对象生成一个唯一的 id，还是它根据时间戳、你的 mac 地址、你的 wifi 信号等的组合做一些不同的事情 pp.

Answer 1

What I would like to know though is, what exactly does git do to assure commit hashes are always unique even if they do the exact same operations with exactly the same contents.

没有。如果您创建相同的内容，您将获得相同的 SHA-1。

但是，首先，您需要意识到提交的“相同内容”意味着——前提是您没有遇到意外的 SHA-1 冲突¹ 或找到破解 SHA 的方法- 1—您必须创建相同的完整存储库历史记录，直至并包括提交本身，包括所有相同的树、作者姓名、时间戳等。

这是因为提交的内容是您在运行 git cat-file -p <sha-1> 时看到的内容在提交时(加上标记和大小字段，上面写着“此对象属于提交类型”，因此没有简单的方法可以通过创建与先前提交具有​​相同内容的 blob 来破坏事物)。这是一个例子:

$ git cat-file -p 996b0fdbb4ff63bfd880b3901f054139c95611cf
tree e760f781f2c997fd1d26f2779ac00d42ca93f534
parent 6da748a7cebe3911448fabf9426f81c9df9ec54f
parent 740c281d21ef5b27f6f1b942a4f2fc20f51e8c7e
author Junio C Hamano <gitster@pobox.com> 1406140600 -0700
committer Junio C Hamano <gitster@pobox.com> 1406140600 -0700

Sync with v2.0.3

* maint:
  Git 2.0.3
  .mailmap: combine Stefan Beller's emails
  git.1: switch homepage for stats

请注意，此字符串包括树及其 SHA-1、此提交的父 SHA-1、作者和时间戳、提交者和时间戳以及消息。如果您更改其中的哪怕一个一点——例如通过尝试更改底层树，或使用一些不同的父提交——您将得到一个新的、不同的 SHA-1，而不是996b0fdbb4ff63bfd880b3901f054139c95611cf .

所以这个问题的答案:

So in theory if me and you do exactly the same steps at exactly the same time with exactly the same configured author, email etc, we would actually get the same commit SHA key?

是"is"。但是......你必须从相同的暂存区开始(这将成为 tree )，并且相同的父提交。如果你然后配置你的作者，电子邮件等，与另一个人完全相同，并且你们都在同一秒创建一个新的提交(或使用 git 的环境变量² 来强制时间邮票)，你们都得到了相同的新提交。

这正是我们想要的。不管是你创建，当你命名为“我”，还是我创建，当我命名为“我”，如果其余所有内容都相同。因为无论谁创建它，另一个“我”都可以克隆它，然后我们也都拥有同样的东西。

(如果我想确保创造某些东西的“我”不会与真实的我混淆，我需要添加一些独特的东西，我知道而另一个我不知道。当然，如果我发表这个东西在某个地方，另一个我认识的人知道。但这是签名的、带注释的标签的用途。它们可以包含 GPG 签名。)

---

¹意外散列冲突的几率(对于任何一对对象；对象越多，几率越高)是 2¹⁶⁰ 中的 1，这是......很小。 :-) 增长实际上非常迅速，因此当您拥有一百万个对象时，它大约是二分之一¹²¹。我在这里使用的公式是:

1 - exp(((-(n * (n-1)))/(2 * r))

其中 r = 2¹⁶⁰ 和 n 是对象的数量。不从 1 中减去，方程式计算“安全裕度”，可以说是:我们不会发生意外哈希冲突的机会。如果我们想将这个数字保持在与磁盘驱动器不会读回错误文件内容的安全裕度相同的范围内——或者至少，磁盘制造商声称——我们需要将它保持在 10 左右^-18，这意味着我们需要避免在我们的 git 数据库中放置超过大约 1.7 千万亿 (1.7E15) 个对象。

²您可以设置许多 git 环境变量来覆盖各种默认值。作者和提交者的那些，包括日期和电子邮件，是:

• GIT_AUTHOR_NAME
• GIT_AUTHOR_EMAIL
• GIT_AUTHOR_DATE
• GIT_COMMITTER_NAME
• GIT_COMMITTER_EMAIL
• GIT_COMMITTER_DATE
• 电子邮件

如 git commit-tree documentation 中所述.