在我的回购中，最长的哈希前缀需要多长时间才能防止重叠？

--abbrev-commit标志可与git log和git rev-list一起使用，以显示部分前缀而不是提交对象的全部40个字符的SHA-1哈希值。按照Pro Git book，在我的回购中，最长的哈希前缀需要多长时间才能防止重叠？

它默认使用七个字符，但使他们更长，如果有必要保持SHA-1歧义[...]

此外，短的SHA至少4-字符长。仍然根据Pro Git书，

一般来说，8到10个字符绰绰有余在项目中是唯一的。

作为一个例子，Linux内核是一个超过450k提交和360万个对象的相当大的项目，没有两个对象的SHA-1重叠超过前11个字符。

由于为防止提交对象的所有前缀哈希值（在Linux内核的情况下为11）所需的最长前缀的长度是回购规模的粗略指标，所以我想以编程方式确定我自己的本地存储库中的相应数量。我怎样才能做到这一点？

来源

2015-09-04 Jubobs

你的意思是http://stackoverflow.com/a/21015031/3691891？ –

@ArkadiuszDrabczyk不完全。您的链接仅提供了一种方法，用于确定给定提交哈希的前缀可以多短以避免与其他哈希值重叠。我要求存储库中所有提交散列的数量最大。 – Jubobs

如果不检查回购库中的所有提交，您无法*严格*确定所需的前缀长度。原则上，回购可能只有两个提交，其前39个字符相同。实际所需的长度可能随着下一次提交而改变。 –

以下shell脚本在本地repo中运行时，会输出所需最长前缀的长度，以防止该存储库的提交对象的所有前缀哈希值之间发生重叠。

MAX_LENGTH=4; 

git rev-list --abbrev=4 --abbrev-commit --all | \ 
    (while read -r line; do 
     if [ ${#line} -gt $MAX_LENGTH ]; then 
     MAX_LENGTH=${#line}; 
     fi 
    done && printf %s\\n "$MAX_LENGTH" 
)

我最后一次编辑这个答案，脚本印刷

“9”在Git-project repo的克隆运行时，
“9”在OpenStack repo的克隆运行时，
当在Linux-kernel repo的克隆中运行时为“11”。

来源

2015-09-04 20:28:41 Jubobs

Jubob的脚本非常棒，向上投票。

如果你想获得最低提交哈希长度的分布的概念，你可以运行此一行代码：

git rev-list --abbrev=4 --abbrev-commit --all | (while read -r line; do echo ${#line}; done;) | sort -n | uniq -c

对于git project本身今日（GIT-上GIT），这会产生这样的：

...得到提交，可以唯一地与 -char散列来表示（或更低，这是GIT中的最低缩写），和提交需要 -of-40个字符的散列，以便唯一地选择它们。

相比之下，一个更大的项目，如Linux kernel，有这个分布今天：

拥有近500万个对象的数据库

所以和600K承诺，有犯下目前要求的11 40个十六进制数字以区别于其他所有提交。

来源

2016-05-24 01:49:28 javabrett

在我的回购中，最长的哈希前缀需要多长时间才能防止重叠？

回答

相关问题