运行git stash;Git stash pop解决了我的问题

我在写提交信息的时候电脑死机了。重新启动后，工作树就像我离开时一样，我能够成功提交我的更改。

然而，当我试图运行git状态时，我得到了

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

与大多数其他答案不同，我并没有试图恢复任何数据。我只是需要Git停止抱怨空对象文件。

概述

“目标文件”是Git对您所关心的实际文件的散列表示。Git认为它应该有一个/文件的散列版本。无论存储在.git/object/xx/12345中的是什么，修复这个错误基本上就是找出“松散对象”应该表示哪个文件的问题。

细节

可能的选择似乎是

删除空文件 将文件转换为Git可以接受的状态

方法1:删除目标文件

我尝试的第一件事就是移动object文件

mv .git/objects/xx/12345 ..

但这并没有起作用——Git开始抱怨断开的链接。关于方法二。

方法2:修复文件

Linus Torvalds写了一篇关于如何恢复目标文件的文章，为我解决了这个问题。这里总结了关键步骤。

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

这告诉你空对象应该是哪个文件的哈希值。现在你可以修理了。

$> git hash-object -w path/to/your_file.whatever

在这样做之后，我检查了. Git /objects/xx/12345，它不再是空的，Git停止抱怨。

在虚拟机上工作，在我的笔记本上，电池没电了，得到这个错误;

error: object file .git/objects/ce/theRef为空 文件.git/objects/ce/theRef是空的 (存储在.git/objects/ce/theRef中)已损坏

我设法让回购工作再次只有2个命令，而没有丢失我的工作(修改文件/未提交的更改)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

在那之后，我运行了git状态，回购很好，有我的更改(等待提交，现在就做…)

Git版本1.9.1

请记住备份您所记得的所有更改，以防此解决方案不起作用，需要更激进的方法。

垃圾收集解决了我的问题:

git gc --aggressive --prune=now

它需要一段时间才能完成，但是每个松散的对象和/或损坏的索引都是固定的。

我刚刚经历了这种情况——我的机器在写到Git回购时崩溃了，它被损坏了。我是这样修正的。

我首先查看有多少提交没有推送到远程回购，如下所示:

gitk &

如果你不使用这个工具，它是非常方便的——据我所知，在所有操作系统上都可用。这表明我的远程缺少两次提交。因此，我单击了指示最新远程提交的标签(通常是/remotes/origin/master)来获得哈希值(哈希值有40个字符长，但为了简洁起见，我在这里使用10个字符——这通常是可行的)。

下面就是:

14c0fcc9b3

然后我点击下面的提交(即远程没有的第一个)，并获得哈希值:

04d44c3298

然后我使用这两个来为这次提交做一个补丁:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

然后我对另一个缺失的提交也做了同样的处理，即我使用了之前提交的哈希值和提交本身的哈希值:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

然后我移动到一个新的目录，从远程复制回购:

git clone git@github.com:username/repo.git

然后我将补丁文件移动到新文件夹中，应用它们并提交它们与它们确切的提交消息(这些可以从git日志或gitk窗口中粘贴):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

这为我恢复了东西(注意，对于大量的提交，可能有更快的方法来做到这一点)。然而，我很想看看损坏的回购树是否可以修复，答案是可以。使用如上所述的修复的repo，在损坏的文件夹中运行这个命令:

git fsck 

你会得到这样的结果:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

要进行修复，我将在损坏的文件夹中这样做:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

即删除损坏的文件，并用一个好的文件替换它。你可能要做几次。最后，你可以运行fsck而不会出现错误。你可能会在报告中出现“悬空提交”和“悬空blob”行，这是你在这个文件夹中重新创建和修改的结果，这是OK的。垃圾收集器将在适当的时候清除它们。

因此(至少在我的情况下)损坏的树并不意味着丢失未推送的提交。

对我来说，这是由于在做git推时发生的电源故障。

这些信息是这样的:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

我尝试了git fsck之类的东西，但这没有帮助。 由于崩溃发生在git推送期间，它显然发生在客户端重写期间，发生在服务器更新之后。我环顾四周，发现c2388在我的例子中是一个提交对象，因为它是由.git/refs中的条目引用的。所以我知道，当我查看历史(通过web界面或第二个克隆)时，我将能够找到c2388。

在第二个克隆中，我执行了git log -n 2 c2388来识别c2388的前身。然后我手动修改了.git/refs/heads/master和.git/refs/remotes/origin/master作为c2388的前身，而不是c2388。 然后我可以进行git取回。 git获取失败了几次，因为空对象上的冲突。我删除了这些空对象，直到git获取成功。这已经修复了存储库。