Git恢复：“目标文件为空”。如何重新创建树木？ [英] Git recovery: "object file is empty". How to recreate trees?

问题描述

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

发生了什么：

当我试图通过局域网（通过SSH）克隆一个存储库时，Git返回了一个错误信息，说存储库已损坏：

 remote：error：object file ./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4 is empty 
 remote：fatal：loose object 2e223ce259e9e33998d434acc778bc64b393d5d4（存储在./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4中）已损坏
错误：git上传包：git-pack-objects死于错误。 
致命：git upload-pack：由于远程端可能的资源库损坏而中止。 
 remote：由于远程端可能存储库损坏而中止。 
  

我发现某处 git fsck 可以用于诊断腐败，但它并没有告诉我任何新东西：

  git fsck --full 
错误：目标文件./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4为空
致命：松散对象2e223ce259e9e33998d434acc778bc64b393d5d4（存储在./objects/2e/223ce259e9e33998d434acc778bc64b393d5d4中）已损坏
  

我试着在本地克隆版本库（使用 - no-hardlinks ）来查看会发生什么，但是我得到完全相同的结果。

然后我偶然发现了这个问题，回答的人刚刚删除了空文件（第3步），所以我做了这个（即我删除了文件 223ce259e9e33998d434acc778bc64b393d5d4 来自子目录 objects / 2e / ）。

git fsck 再次，我看到：

 检查对象目录：100％（256/256），done。从树838e437f371c652fa4393d25473ce21cbf697d7a 
 
损坏的链接，以树2e223ce259e9e33998d434acc778bc64b393d5d4 
悬挂承诺54146bc0dc4eb3eede82a0405b749e05c11c5522 
缺少树2e223ce259e9e33998d434acc778bc64b393d5d4 
悬挂承诺864864feec207786b84158e526b2faec7799fd4e 
悬挂一滴d3cfd7cc7718d5b76df70cf9865db01c25181bfb 
  

所以，现在有一个树 838e437f37 的问题。这不是上面提到的那个家伙发生的事情，所以我去谷歌搜索并找到来自Linus的一些信息。

因此，我做了 git ls-tree 838e437f371c652fa4393d25473ce21cbf697d7a ，并在输出中有一行内容如下：

  040000 tree 2e223ce259e9e33998d434acc778bc64b393d5d4 moje 
  

现在，moje是一个目录Linus解释的例子，这是一个文件）。我猜这就是为什么Linus提出的下一步，为什么 git hash-object moje 返回致命：无法散列moje 。

但无论如何，这只是我需要的一小部分机会，所以我继续往前看。我运行了 git log --raw --all --full-history - moje / 并且根据Linus的指南，应该有一个提交列出2e223作为SHA -2部分内容的散列，但没有。并且该列表以

 致命：无法读取源代码树（2e223ce259e9e33998d434acc778bc64b393d5d4）
  

我试着查看错误之前列出的最后一个提交，但我没有找到这个哈希。我见过这个，但它没有帮助我，可能是因为 是有问题的版本和工作树的当前状态之间的一些变化。

有一件事可能很重要：在 moje / 里有一个目录 cli / ，它是一个Git仓库本身子模块）。我已经在那里寻找有问题的SHA-2散列，但还没有找到它。

我应该怎么做？

解决方案

使用此命令可以获取包含缺少树的提交列表：

  git rev-list --all | xargs -l -I'{}'sh -c'if git ls-tree -rt {}> / dev / null 2>& 1;然后是真的;否则git log --oneline -1 {}; git ls-tree -r -t {} |尾巴-1; fi'
  

现在，您需要重新创建缺少的树，方法是将完全相同的内容放在那里当时在那里，然后将该树添加到回购。最简单的方法是重新创建内容，然后将它们提交到回购站（可以随后删除该提交）。

Note: I don't have any before-corruption clone of this repository. I believe my situation is different from others described here, because I'm missing a tree, not a blob.

What happened:

When I tried to clone a repository over LAN (via SSH), Git returned an error saying that the repository is corrupted:

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.

I've found somewhere that git fsck can be used for diagnosing corruption, but it didn't tell me anything new:

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

I've tried cloning the repository locally (using --no-hardlinks) to see what happens, but I got exactly the same results.

Then I've stumbled upon this question, and the guy who answered just deleted the empty file (step 3), so i did this (i.e. i've deleted file 223ce259e9e33998d434acc778bc64b393d5d4 from subdirectory objects/2e/).

git fsck again, and i see:

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

So, there is now a problem with tree 838e437f37. That's not what happened to the guy mentioned above, so I went googling and found some information from Linus.

So, I did git ls-tree 838e437f371c652fa4393d25473ce21cbf697d7a and in the output there was a line reading:

040000 tree 2e223ce259e9e33998d434acc778bc64b393d5d4    moje

Now, "moje" is a directory (unlike the example which Linus explained, which was a file). I guess that's why next step suggested by Linus, git hash-object moje returned fatal: Unable to hash moje.

But anyway, there was just a small chance that it was what I needed, so I went looking further. I ran git log --raw --all --full-history -- moje/ and according to Linus' guide, there should be a commit which lists 2e223 as a SHA-2 hash of some content, but there's none. And the list ends with

fatal: unable to read source tree (2e223ce259e9e33998d434acc778bc64b393d5d4)

I tried looking at the last commit listed before that error, but I didn't find this hash. I've seen this, but it didn't help me, probably because there were some changes between the problematic version and current state of working tree.

There's one thing that may be important: inside moje/ there's a directory cli/ which is a Git repository itself (a submodule). I've looked for the problematic SHA-2 hash there, but haven't found it.

What should I do?

解决方案

Use this command to get a list of the commits that contain your missing tree:

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'

Now you need to recreate the missing tree, by placing the exact same contents in there as you had in there back then and then adding that tree to the repo. The easiest way to do that is probably to just recreate the contents and then commit them to the repo (you can remove that commit afterwards).

这篇关于Git恢复：“目标文件为空”。如何重新创建树木？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！