我的观点是,应该可以获得重复的git哈希,因为哈希码是唯一性的精简表示,因此会有一些步骤产生相同的哈希码.更重要的是,应该有一系列步骤,其中提交不同的更改但产生相同的哈希码.
例如,在同一台机器上两次克隆相同的存储库,在不同的存储库中进行几乎完全相同的更改(保存一个字节或一位)并提交.即使在提交中使用目录名称或时间戳,仍应该可以获得此目的(尽管很少见).例如,两台不同机器上的两个独立的人同时进行提交.
我的问题是双重的.怎么会发生这种情况,Git将如何处理它.
或者更明确地说,git如何确保您在推送之前保持最新状态.是否有可能一个人先推,然后另一个人尝试推送(两个更改都基于相同的父提交),Git看到哈希码与远程和本地历史相匹配,决定你是好的去,允许你推,但你刚丢失了一个更改？在这种情况下,我看到它更像是以下内容:
repo1 a-> b-> c1
repo2 a-> b-> c1' - > c2
说c1,c1',c2都发生在两个repos被克隆到b后,现在repo1推,没有问题现在repo2试图推c1'和c2和git确定c1'= c1但实际上它们不同,git推c2 ontop c1得到a-> b-> c1-> c2我们失去了c1'的变化
这可能吗？怎么可能发生,git会做什么？
关于与重复哈希相关的问题部分:
Git完全依赖于生成的哈希的唯一性,据我所知,没有安全措施来处理产生相同哈希值的不同数据blob.但是,发生哈希冲突的可能性很小,实际上可以忽略不计.如果您仍然担心,Pro Git的这一部分可能让您放松心情:
更高的可能性是你的编程团队的每个成员都会在同一天晚上被无关紧要的事件中的狼袭击和杀死.
至于你问题的第二部分(会发生什么):
如果你碰巧提交的哈希值与存储库中的前一个对象具有相同的SHA-1值,Git将会在Git数据库中看到前一个对象,并假设它已经被写入.如果您尝试在某个时刻再次检出该对象,您将始终获得第一个对象的数据.
| 归档时间： |
|
| 查看次数： |
1882 次 |
| 最近记录： |