git - 10个十六进制数字git hash缩写就够了吗？

Question

需要多少个可能的哈希值才能避免N项目之间的冲突？如果你回想生日悖论，答案就比这个小得多N。

让我们把问题反过来：对于N=16^10可能的哈希值，它对应于 10 个十六进制数字的缩写 git 修订代码，有多少修订，修订哈希重合的概率上升到 50%？直接计算表明，如果您有 1234603 个修订版本，其中两个具有相同 10 位哈希的概率为 50%。

现在，在大型活动存储库中，一百万左右的修订并非闻所未闻。这里有人在你的工作中经历过 git hash 冲突吗？从理论上讲，这应该发生了。

Answer 1

随着对象数量的增加，Git 会自动缩放缩写哈希的长度，因此这通常不是问题。此外，如果一个缩写的散列在正常长度下是不明确的，Git 会自动生成一个更长的、明确的值。一些命令允许您使用一个选项来控制缩写的长度，--abbrev如果您想要一个特定的值，该core.abbrev选项可以覆盖默认值。

但是，这些名称必须仅在创建时是唯一的，因此如果您正在生产需要使用修订版的工具，它们应该始终对完整的对象 ID 进行操作。另请注意，正在切换到使用 SHA-256 的工作正在进行中，因此在编写工具时，您不应假设特定完整对象 ID 的长度。

Answer 2

正如“通常认为需要多少 Git SHA才能唯一标识给定代码库中的更改？ ”中所解释的那样，您可以获得所需的最小长度git rev-parse --short

 git rev-parse --short=4

但如果你想确定，并且只使用完整的长度：

在 Git 2.31（2021 年第一季度）中，可以将配置变量“core.abbrev”设置为“no”以强制不使用缩写，而不管哈希算法如何。

当Git 从 SHA1 切换到 SHA2时，这将很重要。

请参阅Eric Wong ( ) 的commit a9ecaa0（2020 年 9 月 1 日）。^{（由Junio C Hamano 合并 -- --在6dbbae1 提交中，2021 年 1 月 15 日）}ele828
gitster

core.abbrev=no: 禁用缩写

^{签字人：Eric Wong}

这允许用户通过禁用缩写来编写与哈希无关的脚本和配置。

在 SHA-256 中使用“ -c core.abbrev=40”是不够的，而“ -c core.abbrev=64”现在不适用于 SHA-1 存储库。

[jc：调整了实现，添加了文档和测试]

git config现在在其手册页中包含：

如果设置为“no”，则不进行缩写并且对象名称以其全长显示。