这可能永远不会发生在现实世界中,并且可能永远不会发生,但让我们考虑一下:假设您有一个git存储库,进行提交,并且变得非常不幸:其中一个blob最终拥有相同的SHA-1另一个已存在于您的存储库中.问题是,Git将如何处理这个？简直失败了？找到一种方法来链接两个blob并根据上下文检查哪一个需要？
更多的是脑筋急转弯而非实际问题,但我发现这个问题很有趣.
为了实验,我们假设您git log标识了以下提交
commit 16bc8486fb34cf9a6faf0f7df606ae72ad9ea438 // added 2nd file
commit 9188f9a25b045f130b08888bc3f638099fa7f212 // initial commit
提交后,.git/refs/heads/master指向16bc8486fb34cf9a6faf0f7df606ae72ad9ea438.
让我们说,在此之后,我手动编辑.git/refs/heads/master文件指向9188f9a25b045f130b08888bc3f638099fa7f212
此时,git status会识别出一个新的未提交文件需要引起注意.这是我第二次提交之前处理的文件.
如果我确实提交它.. git log现在显示
commit b317f67686f9e6ab1eaabf47073b401d677205d5 // 2nd file committed for the 2nd time
commit 9188f9a25b045f130b08888bc3f638099fa7f212 // initial commit
问题1:
你会注意到SHA我第一次提交第二个文件和现在之间的哈希值是不同的.这是为什么？文件的内容没有改变,它仍然是完全相同的文件.
问题2
在这一点上,原来的第二次提交发生了什么？当我这样做时git show 16bc8486,它显示了这个提交.然而,它并没有出现在git log历史中.