提交的SHA-1是否仅基于树的内容计算？

Question

为了实验,我们假设您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历史中.

Answer 1

问题1:因为哈希是在考虑所有因素的情况下生成的,包括提交元数据(其本身包含日期和时间).

问题2:git log显示当前分支的日志.提交16bc8486不是它的一部分.据我所知(我不完全确定)垃圾收集器迟早会把它带走,如果它发现没有引用它(git gc --help)..

Answer 2

如果您具有相同的内容(即使文件名已更改),则每种文件blob的sha1值在两种情况下都是相同的.

同样,如果文件blob 的树的sha1值具有相同的文件名,则它们将是相同的.

但是在最顶层我们有提交,它将包含前一个提交,顶层树,作者和提交者的未更改的链接,但正如KingCrunch所说,作者和提交者日期将不同,因此提交sha1的sha1会有所不同.

如果您故意使用环境变量设置作者和提交者日期以使它们保持不变,则可以使它们相同.