相关疑难解决方法(0)

这可能永远不会发生在现实世界中,并且可能永远不会发生,但让我们考虑一下:假设您有一个git存储库,进行提交,并且变得非常不幸:其中一个blob最终拥有相同的SHA-1另一个已存在于您的存储库中.问题是,Git将如何处理这个？简直失败了？找到一种方法来链接两个blob并根据上下文检查哪一个需要？

更多的是脑筋急转弯而非实际问题,但我发现这个问题很有趣.

给定两个不同的字符串S1和S2(S1!= S2)可能是:

SHA1(S1) == SHA1(S2)

是真的？

1. 如果是 - 有什么概率？
2. 如果没有 - 为什么不呢？
3. 输入字符串的长度是否有上限,获取重复的概率为0？OR是SHA1的计算(因此重复的概率),与字符串的长度无关？

我想要实现的目标是散列一些敏感的ID字符串(可能与其他字段(如父ID)连接在一起),这样我就可以使用散列值作为ID(例如在数据库中).

例:

Resource ID: X123
Parent ID: P123

我不想公开我的资源标识的性质,以允许客户端看到"X123-P123".

相反,我想创建一个新的列散列("X123-P123"),让我们说它是AAAZZZ.然后客户端可以请求ID为AAAZZZ的资源,而不知道我的内部id等.

给定一组100个相同长度的不同字符串,如何量化字符串的SHA1摘要冲突不太可能的概率？

我有一些脚本可以在我们的主机（Gitlab）中查询项目的所有标签以及标签指向的提交哈希值。然后它对这些哈希值进行更多处理。

这通常是有效的，但我有一个提交，其中我得到的哈希值与该提交上的 git 日志显示的哈希值不同。

问题是，这并不完全错误。返回的哈希值确实可以让我检查正确的提交：

>>git checkout 6a923
HEAD is now at ae67e044

和

>>git log -1 6a923
commit ae67e044359c86781fd7c1b74016f858f00584f8 (HEAD, tag: <correct tag>)

但当我稍后想做类似比较哈希之类的事情时，它显然不起作用。

我认为哈希是唯一的。这似乎是某种别名哈希。这里发生了什么？

附加信息：

>>git cat-file -p 6a923
object ae67e044359c86781fd7c1b74016f858f00584f8
type commit
tag <correct tag>
tagger <correct tagger> 1558448485 -0400