如何在git中消除模糊的缩写sha1

Josh Stone对sha1缩写碰撞的分析让我很感兴趣。

假设某人在明确的时候写下了一个缩写的提交ID 8b82547e33 。 但是从那时起，其他的对象已经被创build了相同的前缀，所以现在git告诉你（出于某种原因两次）：

 $ git show 8b82547e33 error: short SHA1 8b82547e33 is ambiguous. error: short SHA1 8b82547e33 is ambiguous. fatal: ambiguous argument '8b82547e33': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' 

现在，作为一个人，我可能会告诉我是哪个对象，如果git会让我看到模糊的对象。 我怎样才能达到像下面这样的东西？

 $ git objects-starting-with 8b82547e33 8b82547e33e: commit: l2tp: Restore socket refcount when sendmsg succeeds 8b82547e338: tree [2 files, 26 subtrees] 

（注意：上面的例子使用了一个相对较新的http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git） 。

Answer 1

你可以使用git rev-parse ，假设你至less有一个4位的完整散列前缀。

 git rev-parse --disambiguate=8b82547e33 

Answer 2

有了Git 2.11+（Q4 2016），你甚至不必inputgit rev-parse --disambiguate=...

Git会列出你可能的候选人！

请参阅提交date 2016年9月27日（ 提交 ） Jeff King（ peff ） 提交1ffa26c ， 提交fad6b9e ， 提交16ddcd4 ， 提交0c99171 ， 提交59e4e34 ， 提交0016043 ， 提交5d5def2 ， 提交8a10fea ， 提交7243ffd ， 提交259942f 。
^{（由Junio C gitster合并- gitster -在提交66c22ba ，2016年10月06日）}

get_short_sha1 ：列出错误的模糊对象

当用户给我们一个模糊的短sha1，我们打印一个错误，并拒绝解决它。
在某些情况下，下一步是为他们提供更多的人物（例如，如果他们正在重新打字或从一个完整的sha1粘贴）。 但在其他情况下，这可能就是他们所拥有的一切。

例如，旧的提交消息可能使用了当时唯一的7个字符的hex，但现在不明确。
Git没有提供任何有关它find的模糊对象的信息，所以用户很难找出它们可能意味着哪一个。

这个补丁教导了get_short_sha1()列出它find的对象的sha1s，以及一些可能帮助用户决定它们意味着什么的信息 。
下面是它在git.git上的样子 ：

  $ git rev-parse b2e1 error: short SHA1 b2e1 is ambiguous hint: The candidates are: hint: b2e1196 tag v2.8.0-rc1 hint: b2e11d1 tree hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options' hint: b2e1759 blob hint: b2e18954 blob hint: b2e1895c blob fatal: ambiguous argument 'b2e1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' 

我们显示标记的标记名，以及提交的date和主题。
对于树木和斑点，理论上我们可以挖掘历史，find它们所在的path。 但是这非常昂贵（对于内核来说大约是30s），而且这不太可能有帮助。
大多数简短的引用是提交，所以有用的信息通常会是有问题的对象不是提交。 所以花大量的CPU抢先挖掘path是愚蠢的; 用户可以自己做，如果他们真的需要。

当然，有些讽刺的是，我们在消歧提示中缩写为sha1。
但是完整的sha1s会导致提交行的恼人的换行，大概用户会立即用修正的sha1重新发出他们的命令。

我们还将列表限制为与消歧提示相匹配的列表。 例如：

  $ git rev-parse b2e1:foo error: short SHA1 b2e1 is ambiguous hint: The candidates are: hint: b2e1196 tag v2.8.0-rc1 hint: b2e11d1 tree hint: b2e1632 commit 2007-11-14 - Merge branch 'bs/maint-commit-options' fatal: Invalid object name 'b2e1'. 

不用担心报告斑点，因为它们不能像树木一样工作。