相关疑难解决方法(0)

我读到Git使用SHA-1摘要作为修订版的ID.为什么不使用更现代的SHA版本？

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

让我们说有人写下了一个缩写的提交ID 8b82547e33,在它明确无误的时候.但从那时起,其他对象已经创建了相同的前缀,所以现在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的相对最新的克隆.)

Git 允许使用以下命令检索提交的哈希值：

git rev-parse HEAD

这给出33b316c 或

git rev-parse --short HEAD

这让33b316cbeeab3d69e79b9fb659414af4e7829a32 我知道实践中长哈希永远不会发生冲突。

在实践中，短哈希值的使用更为频繁。我想知道短的碰撞的概率是多少？git 是否采取任何措施来克服可能的冲突（例如使用时git checkout）？