当我尝试提交更改时,我得到这个错误:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

我尝试了我得到的 git fsck:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

如何解决这个错误?


当前回答

因为我必须定期重启我的虚拟机,不知何故这个问题经常发生在我身上。几次之后,我意识到我不能每次都重复Nathan Vanhoudnos所描述的过程,尽管它总是有效的。然后我想出了以下更快的解决方案。

步骤1

将整个存储库移动到另一个文件夹。

mv current_repository temp_repository

步骤2

再次从原点克隆存储库。

git clone source_to_current_repository.git

步骤3

删除新存储库下的所有内容,除了.git文件夹。

步骤4

将temp_repository中的所有内容移到新的存储库中,除了.git文件夹。

步骤5

删除temp_repository,就完成了。

几次之后,我相信你可以很快地完成这些步骤。

其他回答

我遇到了同样的问题,我用了一个非常简单的方法来解决它。我发现那些丢失的文件存在于我队友的电脑上。

我将这些文件一个一个地复制到Git服务器(总共9个文件),这样就解决了这个问题。

让我们简单点…只有在将源代码上传到远程Git存储库的情况下

备份你的。git文件夹 检查Git存储库 Git FSCK—满 删除空目标文件(全部) rm / 8 b / 61 d0135d3195966b443f6c73fb68466264c68e . /对象 再次检查Git存储库。 Git FSCK—满 从远程Git存储库中提取源代码 Git拉源主

我解决了这个问题,删除了git fsck检测到的各种空文件,然后运行一个简单的git拉。

我感到失望的是,现在即使文件系统实现了日志记录和其他“事务性”技术来保持文件系统正常运行,Git也会因为设备上的电源故障或空间问题而进入损坏状态(并且无法自行恢复)。

如果你在github.com上的公共存储库正常工作,但你的本地存储库损坏,这里有一种解决问题的方法。请注意,您将丢失在本地存储库中所做的所有提交。

我有一个本地存储库,给我这个对象空错误,github.com上的同一个存储库,但没有这个错误。因此,我所做的只是从GitHub克隆存储库,然后从损坏的存储库中复制所有内容(除了.git文件夹),并将其粘贴到正在工作的克隆存储库中。

这可能不是一个实用的解决方案(因为您删除了本地提交),但是,您维护代码和修复的版本控制。

请记住在应用此方法之前进行备份。

我假设你有一个遥控器,所有相关的变化已经推送到它。我不关心本地更改,只是希望避免删除和重新克隆大型存储库。如果您确实有重要的局部更改,您可能需要更加小心。

我的笔记本电脑死机后也遇到了同样的问题。 可能是因为它是一个很大的存储库,我有相当多的损坏的对象文件,当调用git fsck—full时,每次只出现一个,所以我写了一个小的shell一行程序来自动删除其中一个:

$ sudo rm ' git fsck,满2 > & 1 | grep oe - m 1 " . /对象/ [0-9a-f] {2} [0-9a-f] *”的

2>&1将错误消息重定向到标准输出,以便能够对其进行grep 使用的Grep选项: -o只返回行中实际匹配的部分 -E启用高级正则表达式 -m 1确保只返回第一个匹配项 [0-9a-f]{2}匹配0到9之间的任意字符,如果a和f同时出现,则匹配a和f [0-9a-f]*匹配0到9之间且a和f同时出现的任意数量的字符

它一次仍然只删除一个文件,所以你可能想在循环中调用它,就像:

$ while为true;做sudo rm的git fsck,满2 > & 1 | grep oe - m 1 " . /对象/ [0-9a-f] {2} [0-9a-f] *”的;完成

这样做的问题是,它不再输出任何有用的东西,所以您不知道它什么时候完成(一段时间后它应该不会做任何有用的事情)。

为了“修复”这个问题,我只需要在每一轮之后调用git fsck—full,如下所示: $ while为true;做sudo rm的git fsck,满2 > & 1 | grep oe - m 1 " . /对象/ [0-9a-f] {2} [0-9a-f] *”的;Git FSCK—满;完成

它现在的速度大约是原来的一半,但它确实输出了它的“状态”。

在这之后,我玩了一些建议在这里的答案,最后得到了一个点,我可以得到藏匿和藏匿掉很多破碎的东西。

第一个问题解决了

后来我还是有这样一个问题: 无法解析引用'refs/remotes/origin/$branch':引用破裂,可以通过 $ rm \repo.git\refs\remotes\origin$branch

$ git fetch

然后我做了一个 $ git gc -prune=现在

$ git远程修剪来源

为了更好地衡量

Git reflog expire -stale-fix -all

当运行git fsck——full时,清除错误:HEAD: invalid reflog entry $blubb。