63

Git 和 GitHub 都显示 SHA 的短版本——仅显示前 7 个字符而不是全部 40 个字符——并且 Git 和 GitHub 都支持将这些短 SHA 作为参数。

例如git show 962a9e8

例如https://github.com/joyent/node/commit/962a9e8

鉴于可能性空间现在低了几个数量级，“仅” 2.68 亿，Git 和 GitHub 如何在这里防止碰撞？他们如何处理它们？

4

3 回答 3

64

这些简短的表格只是为了简化视觉识别并使您的生活更轻松。Git 并没有真正截断任何内容，内部所有内容都将使用完整值进行处理。不过，您可以在方便时使用部分 SHA-1：

如果您提供前几个字符，只要您的部分 SHA-1 至少有四个字符长且明确——也就是说，当前存储库中只有一个对象以部分 SHA-1。

于 2011-08-20T00:51:07.910 回答
34

我有一个存储库，其提交的 id 为000182eacf99cde27d5916aa415921924b82972c.

git show 00018

显示修订，但

git show 0001

印刷

error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

（如果你好奇，它是 git 本身的 git 存储库的克隆；该提交是 Linus Torvalds 在 2005 年所做的。）

于 2011-08-19T23:55:09.017 回答
14

这里有两个注意事项：

  • 如果您y在显示提交的 GitHub 页面上的任何位置键入，您将看到该提交的完整 40 字节。
    这说明了emboss的观点：GitHub 不会截断任何内容。

  • 无论如何，自 2010 年以来 7 个十六进制数字（28 位）还是不够的。
    请参阅Linus Torwalds 本人的提交 dce9648（2010 年 10 月，git 1.7.4.4）：

默认值 7 来自 git 开发的早期阶段，当时七个十六进制数字很多（它涵盖了大约 250+ 百万个哈希值）。那时我认为 65k 修订很多（这是我们即将在 BK 中实现的），并且每个修订往往是大约 5-10 个新对象左右，所以一百万个对象是一个很大的数字。

(BK = BitKeeper)

如今，内核甚至不是最大的 git 项目，甚至内核也有大约 220k 的修订版（比 BK 树大得多），我们正在接近 200 万个对象。到那时，七个十六进制数字对于其中的许多人来说仍然是唯一的，但是当我们谈论对象数量和散列大小之间只有两个数量级的差异时，截断的散列值会发生冲突。它甚至不再接近不现实——它一直在发生。

我们应该增加不切实际的小默认缩写，并添加一种方法让人们在 git 配置文件中为每个项目设置自己的默认缩写。

于 2014-01-09T08:16:17.193 回答