Git 恢复：“目标文件为空”。如何重新创建树木？

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

发生了什么：

当我尝试通过 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）看看会发生什么，但我得到了完全相同的结果。

然后我偶然发现这个问题，而回答的人刚刚删除了空文件（步骤 3），所以我这样做了（即我已经删除了文件223ce259e9e33998d434acc778bc64b393d5d4从子目录objects/2e/).

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。这不是上面提到的那个人发生的事情，所以我去谷歌搜索发现来自 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，但这对我没有帮助，可能是因为were有问题的版本和工作树的当前状态之间的一些变化。

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

我应该怎么办？

命令（由 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 to c0b1a24。我去了子模块存储库并询问这两者之间发生了什么提交：

git log --oneline 640a825..c0b1a24

返回的

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

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

• somefile被删除
• /moje/cliHEAD 已更改为640a825 to 02564e1
• /moje/cliHEAD 已更改为02564e1 to 8be9433
• /moje/cliHEAD 已更改为8be9433 to c0b1a24

我不知道哪一部分发生在499b8fb（错误的提交），并且在89b0fc4。但幸运的是，可能性并不多，所以我只是尝试了每一种。对于每个组合，我都会进行提交，以便 Git 计算适当的对象并将它们存储在数据库中。原来，当/moje/cliHEAD 位于8be9433, git commit导致创建了失踪的2e223ce对象 - 万岁！

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

我想那是因为git show somesha显示了引入了哪些更改somesha，为此，Git 需要读取上一次提交的内容（在本例中是损坏的提交）。显然，Git 不需要查看前一次提交来检查一次。

（我成功地做到了这要归功于克罗尼尔的回答- 向他致敬！建议我将此作为我自己的答案发布。）