10个十六进制数字git hash缩写足够吗？

Question

一个人需要多少个哈希值才能避免在N个项目之间发生冲突？如果您回想起birthday paradox，答案要比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

如“How much of a Git SHA is generally considered necessary to uniquely identify a change in a given codebase?”中所述，您可以使用 git rev-parse --short

获得所需的最小长度

 git rev-parse --short=4

但如果你想确定，并且只使用全长：

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

这在 Git will switch from SHA1 to SHA2 时很重要。

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

<块引用>

core.abbrev=no：禁用缩写

^{签字人：Eric Wong}

<块引用>

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

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

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

git config 现在包含在其 man page 中：

<块引用>

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