Git(Hub)如何处理来自短SHA的可能冲突？

Question

Git(Hub)如何处理来自短SHA的可能冲突？

Ase*_*ore 53 git cryptography github sha

Git和GitHub都显示SHAs的短版本 - 只是前7个字符而不是全部40个 - 并且Git和GitHub都支持将这些简短的SHA作为参数.

例如 git show 962a9e8

例如https://github.com/joyent/node/commit/962a9e8

鉴于可能性空间现在降低了几个数量级,"仅" 2.68亿,Git和GitHub如何防止碰撞？他们如何处理它们？

Answer 1

emb*_*oss 57

这些简短形式只是为了简化视觉识别并使您的生活更轻松.Git并没有真正截断任何内容,内部的所有内容都将使用完整的值来处理.您可以在方便时使用部分SHA-1:

如果你提供前几个字符,Git足够聪明,可以找出你想要输入的提交内容,只要你的部分SHA-1长度至少为4个字符并且是明确的 - 也就是说,当前存储库中只有一个对象以部分SHA-1.

谢谢!该链接进一步阐述:"Git可以为SHA-1值找出一个简短的,唯一的缩写.如果将`--abbrev-commit`传递给git log命令,输出将使用较短的值,但保持它们唯一;它默认使用七个字符,但如果需要保持SHA-1明确,则使它们更长." (11认同)
另一个有用的引用:"一般来说,8到10个字符足以在项目中独一无二.最大的Git项目之一,Linux内核,在可能的40个字符中开始需要12个字符才能保持独特." (10认同)

Answer 2

Kei*_*son 30

我有一个存储库,其id为的提交000182eacf99cde27d5916aa415921924b82972c.

git show 00018

Run Code Online (Sandbox Code Playgroud)

显示修订版,但是

git show 0001

Run Code Online (Sandbox Code Playgroud)

版画

error: short SHA1 0001 is ambiguous.
error: short SHA1 0001 is ambiguous.
fatal: ambiguous argument '0001': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

Run Code Online (Sandbox Code Playgroud)

(如果你很好奇,那就是git本身的git存储库的克隆;那个提交是Linus Torvalds在2005年提出的.)

如果你需要知道哪些对象与你的模糊id(在这种情况下是'0001`)匹配,你可以做`git rev-list --all --objects | grep ^ 0001`.在列出可能的完整SHA1之后,您可以为每个SHA1执行`git show`. (7认同)

Answer 3

Von*_*onC 12

这里有两个注释:

如果您y在显示提交的GitHub页面上的任何位置键入,您将看到所述提交的完整40个字节.
这说明了浮雕的观点:GitHub不会截断任何内容.
无论如何,自2010年以来,7个十六进制数字(28位)是不够的.
请参阅Linus Torwalds本人提交的dce9648(2010年10月,git 1.7.4.4):

默认值7来自git开发的相当早期,当七个十六进制数字很多时(它涵盖大约2.5亿个哈希值).那时候我认为65k的修改很多(这是我们要用BK命中的),并且每个版本往往大约有5-10个新对象,所以一百万个对象是一个很大的数字.

(BK = BitKeeper)

这些天来,内核甚至不是最大的Git项目,甚至内核约220K版本(多比BK树曾是大),我们正在接近200万级的对象.此时,七个十六进制数字对于它们中的许多仍然是唯一的,但是当我们谈论对象数量和散列大小之间仅有两个数量级的差异时,在截断的散列值中将存在冲突.它甚至不再接近不切实际 - 它总是发生.

我们都应该增加不切实际的小默认缩写,并为人们添加一种在git配置文件中设置自己的默认每个项目的方法.

归档时间：	14 年，4 月前
查看次数：	12081 次
最近记录：	7 年，8 月前