需要多少个可能的哈希值才能避免N
项目之间的冲突?如果你回想生日悖论,答案就比这个小得多N
。
让我们把问题反过来:对于N=16^10
可能的哈希值,它对应于 10 个十六进制数字的缩写 git 修订代码,有多少修订,修订哈希重合的概率上升到 50%?直接计算表明,如果您有 1234603 个修订版本,其中两个具有相同 10 位哈希的概率为 50%。
现在,在大型活动存储库中,一百万左右的修订并非闻所未闻。这里有人在你的工作中经历过 git hash 冲突吗?从理论上讲,这应该发生了。
需要多少个可能的哈希值才能避免N
项目之间的冲突?如果你回想生日悖论,答案就比这个小得多N
。
让我们把问题反过来:对于N=16^10
可能的哈希值,它对应于 10 个十六进制数字的缩写 git 修订代码,有多少修订,修订哈希重合的概率上升到 50%?直接计算表明,如果您有 1234603 个修订版本,其中两个具有相同 10 位哈希的概率为 50%。
现在,在大型活动存储库中,一百万左右的修订并非闻所未闻。这里有人在你的工作中经历过 git hash 冲突吗?从理论上讲,这应该发生了。
随着对象数量的增加,Git 会自动缩放缩写哈希的长度,因此这通常不是问题。此外,如果一个缩写的散列在正常长度下是不明确的,Git 会自动生成一个更长的、明确的值。一些命令允许您使用一个选项来控制缩写的长度,--abbrev
如果您想要一个特定的值,该core.abbrev
选项可以覆盖默认值。
但是,这些名称必须仅在创建时是唯一的,因此如果您正在生产需要使用修订版的工具,它们应该始终对完整的对象 ID 进行操作。另请注意,正在切换到使用 SHA-256 的工作正在进行中,因此在编写工具时,您不应假设特定完整对象 ID 的长度。
正如“通常认为需要多少 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”,则不进行缩写并且对象名称以其全长显示。