Git recovery : "object file is empty". 如何重建树？

Question

注意:我没有此存储库的任何损坏前克隆。我相信我的情况与这里描述的其他人不同，因为我缺少的是一棵树，而不是一个 Blob 。

发生了什么:

当我尝试通过 LAN(通过 SSH)克隆存储库时，Git 返回一个错误，指出存储库已损坏:

remote: error: object file ./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4 is empty
remote: fatal: loose object 2e223ce259e9e33998d434acc778bc64b393d5d4 (stored in ./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4) is corrupt
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.

我在某处发现 git fsck 可用于诊断损坏，但它没有告诉我任何新信息:

git fsck --full
error: object file ./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4 is empty
fatal: loose object 2e223ce259e9e33998d434acc778bc64b393d5d4 (stored in ./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4) is corrupt

我已经尝试在本地克隆存储库(使用 --no-hardlinks)以查看会发生什么，但我得到了完全相同的结果。

然后我偶然发现了this question ，回答的人刚刚删除了空文件(第 3 步)，所以我这样做了(即我从子目录 objects/2e/ 中删除了文件 223ce259e9e33998d434acc778bc64b393d5d4)。

再次

git fsck，我看到了:

Checking object directories: 100% (256/256), done.
broken link from    tree 838e437f371c652fa4393d25473ce21cbf697d7a
              to    tree 2e223ce259e9e33998d434acc778bc64b393d5d4
dangling commit 54146bc0dc4eb3eede82a0405b749e05c11c5522
missing tree 2e223ce259e9e33998d434acc778bc64b393d5d4
dangling commit 864864feec207786b84158e526b2faec7799fd4e
dangling blob d3cfd7cc7718d5b76df70cf9865db01c25181bfb

所以，树 838e437f37 现在有问题。那不是上面提到的那个人发生的事情，所以我去谷歌搜索并找到了some information from Linus。 .

所以，我执行了 git ls-tree 838e437f371c652fa4393d25473ce21cbf697d7a 并且在输出中有一行内容:

040000 tree 2e223ce259e9e33998d434acc778bc64b393d5d4    moje

现在，“moje”是一个目录(不像 Linus 解释的例子，它是一个文件)。我想这就是为什么 Linus 建议的下一步，git hash-object moje 返回 fatal: Unable to hash moje。

但无论如何，这正是我需要的可能性很小，所以我进一步寻找。我运行了 git log --raw --all --full-history -- moje/ 并且根据 Linus 的指南，应该有一个提交将 2e223 列为某些内容的 SHA-2 哈希, 但没有。列表以

结尾

fatal: unable to read source tree (2e223ce259e9e33998d434acc778bc64b393d5d4)

我尝试查看该错误之前列出的最后一次提交，但没有找到此哈希值。我看过this ，但这对我没有帮助，可能是因为有问题的版本和工作树的当前状态之间存在一些变化。

有一件事可能很重要:在 moje/ 中有一个目录 cli/，它本身就是一个 Git 存储库(一个子模块)。我在那里寻找有问题的 SHA-2 哈希，但没有找到。

我该怎么办？

Answer 1

命令(由 Chronial 建议)

git rev-list --all | xargs -l -I '{}' sh -c 'if git ls-tree -rt {} > /dev/null 2>&1 ; then true; else git log --oneline -1 {}; git ls-tree -r -t {} | tail -1; fi'

返回了第一个依赖于丢失的 2e223ce 对象的提交 - 它的 SHA-2 哈希是 499b8fb。它的父级没问题(我可以看到它的内容，检查它等等)，而且我还能够检查损坏的提交之后的下一个提交 (89b0fc4)。

现在我需要查看这两个“良好”提交之间发生了什么变化 - 这很简单:返回 git diff 499b8fb~ 89b0fc4

diff --git a/somefile b/somefile
deleted file mode 100644
index f5d1e1e..0000000
--- a/somefile
+++ /dev/null
@@ -1,79 +0,0 @@
[ contents of the deleted "somefile"... ]
diff --git a/moje/cli b/moje/cli
index 640a825..c0b1a24 160000
--- a/moje/cli
+++ b/moje/cli
@@ -1 +1 @@
-Subproject commit 640a825cd671dfba83601d6271e7e027665eaca8
+Subproject commit c0b1a24aa246289831ec7db3a8596376db1f625a

现在我知道在错误提交和正确提交之间，文件 somefile 被删除，子模块的 HEAD 从 640a825 更改为 c0b1a24。我去了子模块存储库并询问这两个之间发生了什么提交:

git log --oneline 640a825..c0b1a24

哪个返回了

c0b1a24 <commit message>
8be9433 <commit message>
02564e1 <commit message>

现在我知道在 499b8fb~ 和 89b0fc4 之间发生了四件事:

• somefile 已删除
• /moje/cli HEAD 从 640a825 更改为 02564e1
• /moje/cli HEAD 从 02564e1 更改为 8be9433
• /moje/cli HEAD 从 8be9433 更改为 c0b1a24

我不知道哪个部分发生在 499b8fb(错误提交)中，哪个部分发生在 89b0fc4 中。但幸运的是没有那么多的可能性，所以我只是尝试了每一种。对于每个组合，我都进行了提交，以便 Git 计算适当的对象并将它们存储在数据库中。事实证明，当 /moje/cli HEAD 位于 8be9433 时，git commit 导致创建了丢失的 2e223ce对象 - 万岁!

注意:如果您遇到类似情况并且正在四处查看哪些提交是好的以及 Git 可以告诉您有关它们的哪些信息，请记住能够checkout 提交和show 这是两个不同的东西。例如，我最初认为如果 git show somesha 抛出错误，这意味着 somesha 提交已损坏，我无法将其用于任何事情。结果证明这是错误的:虽然 git show 89b0fc4 返回了错误，但我能够 git checkout 89b0fc4 以及 git diff 499b8fb~ 89b0fc4成功了。

我想那是因为 git show somesha 显示了 somesha 引入了哪些更改，为此 Git 需要读取上一次提交的内容(在本例中为损坏的一个)。显然，Git 不需要查看之前的提交就可以 check out 一个。

(感谢 Chronial's answer，我设法做到了这一点 - 对他表示敬意!我被建议将其发布为我自己的答案。)