注意:您可以要求git rev-parse --short
最短但唯一的 SHA1。
请参阅“ git 从常规散列中获取短散列”
git rev-parse --short=4 921103db8259eb9de72f42db8b939895f5651489
92110
正如您在我的示例中看到的那样,即使我指定长度为 4,SHA1 的长度也为 5。
对于大型回购,自 2010 年以来 7 是不够的,并且由 Linus Torvalds 本人提交 dce9648(git 1.7.4.4,2010 年 10 月):
默认值 7 来自 git 开发的早期阶段,当时七个十六进制数字很多(它涵盖了大约 250+ 百万个哈希值)。
那时我认为 65k 修订很多(这是我们即将在 BK 中实现的),每个修订往往是大约 5-10 个新对象左右,所以一百万个对象是一个很大的数字。
(BK = BitKeeper)
如今,内核甚至不是最大的 git 项目,甚至内核也有大约 220k 的修订版(比 BK 树大得多),我们正在接近 200 万个对象。
到那时,七个十六进制数字对于其中的许多人来说仍然是唯一的,但是当我们谈论对象数量和散列大小之间只有两个数量级的差异时,截断的散列值会发生冲突。
它甚至不再接近不现实——它一直在发生。
我们应该增加不切实际的小默认缩写,并添加一种方法让人们在 git config 文件中设置他们自己的每个项目的默认默认值。
core.abbrev
设置长度对象名称的缩写。
如果未指定,许多命令会缩写为 7 个十六进制数字,这可能不足以让缩写的对象名称在足够长的时间内保持唯一性。
environment.c
:
int minimum_abbrev = 4, default_abbrev = 7;
注意:正如marco.m 在下面评论的那样,在同一 Git 1.7.4.4 中的提交a71f09f中core.abbrevLength
被重命名core.abbrev
重命名core.abbrevlength
回core.abbrev
--abbrev=$n
毕竟它对应于命令行选项。
最近,Linus 在提交 e6c587c中添加(对于 Git 2.11,Q4 2016):(
如Matthieu Moy的回答中所述)
在相当早的时候,我们以某种方式决定将对象名称缩写为 7 位十六进制数字,但随着项目的增长,越来越有可能看到在早期制作的如此短的对象名称并记录在日志消息中不再唯一。
目前 Linux 内核项目需要 11 到 12 个 hexdigits,而 Git 本身需要 10 个 hexdigits 来唯一标识它们拥有的对象,而许多较小的项目可能仍然可以使用原始的 7-hexdigit 的默认值。一种尺寸并不适合所有项目。
引入一种机制,我们在第一次请求时估计存储库中的对象数量,以使用默认设置缩写对象名称,并为存储库提供一个合理的默认值。基于在2^(2N)
使用缩短为前 N 位的对象名称时我们会在存储库中看到与对象发生冲突的预期,使用足够数量的十六进制数字来覆盖存储库中的对象数量。
我们添加到缩短名称的每个十六进制数字(4 位)允许我们在存储库中拥有四倍(2 位)的对象。
请参阅Linus Torvalds ( )的提交 e6c587c(2016 年 10 月 1 日) 。
请参阅Junio C Hamano ( ) 的提交 7b5b772和提交 65acfea(2016 年 10 月 1 日)。(由Junio C Hamano 合并——在提交 bb188d0中,2016 年 10 月 3 日)torvalds
gitster
gitster
这个新属性(猜测 SHA1 缩写值的合理默认值)对Git 如何计算自己的 release 版本号有直接影响。