如何修复 GIT 错误：目标文件为空？

How to fix GIT error: object file is empty?

提问by simo

When I try to commit changes, I get this error:

当我尝试提交更改时，出现此错误：

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

Any idea how to solve this error ?

知道如何解决这个错误吗？

EDIT

编辑

I tried git fsckI've got:

我试过git fsck我有：

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

回答by Nathan VanHoudnos

I had a similar problem. My laptop ran out of battery during a git operation. Boo.

我有一个类似的问题。我的笔记本电脑在 git 操作期间没电了。嘘。

I didn't have any backups. (N.B. Ubuntu One is not a backup solution for git; it will helpfully overwrite your sane repository with your corrupted one.)

我没有任何备份。（注意 Ubuntu One 不是 git 的备份解决方案；它会用损坏的存储库覆盖您正常的存储库。）

To the git wizards, if this was a bad way to fix it, please leave a comment. It did, however, work for me... at least temporarily.

对于 git 向导，如果这是一个不好的修复方法，请发表评论。然而，它确实对我有用……至少是暂时的。

Step 1: Make a backup of .git (in fact I do this in between every step that changes something, but with a new copy-to name, e.g. .git-old-1, .git-old-2, etc.):

第 1 步：备份 .git（实际上，我在每一步更改某些内容之间执行此操作，但使用新的复制对象名称，例如 .git-old-1、.git-old-2 等） ：

cp -a .git .git-old

Step 2: Run git fsck --full

第 2 步：运行 git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Step 3: Remove the empty file. I figured what the heck; its blank anyway.

第 3 步：删除空文件。我想出了什么问题；反正它是空白的。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Step 3: Run git fsckagain. Continue deleting the empty files. You can also cdinto the .gitdirectory and run find . -type f -empty -delete -printto remove all empty files. Eventually git started telling me it was actually doing something with the object directories:

第三步：git fsck再次运行。继续删除空文件。您也可以cd进入该.git目录并运行find . -type f -empty -delete -print以删除所有空文件。最终 git 开始告诉我它实际上是在对对象目录做一些事情：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Step 4: After deleting all of the empty files, I eventually came to git fsckactually running:

第 4 步：删除所有空文件后，我最终开始git fsck实际运行：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Step 5: Try git reflog. Fail because my HEAD is broken.

第 5 步：尝试git reflog。失败，因为我的头坏了。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Step 6: Google. Find this. Manually get the last two lines of the reflog:

第六步：谷歌。找到这个。手动获取reflog的最后两行：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <[email protected]> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <[email protected]> 1347358589 -0400  commit: fixed up to page 28

Step 7: Note that from Step 6 we learned that the HEAD is currently pointing to the very last commit. So let's try to just look at the parent commit:

第 7 步：请注意，从第 6 步我们了解到 HEAD 当前指向最后一次提交。所以让我们试着只看一下父提交：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

It worked!

有效！

Step 8: So now we need to point HEAD to 9f0abf890b113a287e10d56b66dbab66adc1662d.

第 8 步：所以现在我们需要将 HEAD 指向 9f0abf890b113a287e10d56b66dbab66adc1662d。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Which didn't complain.

哪个没有抱怨。

Step 9: See what fsck says:

第 9 步：看看 fsck 怎么说：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Step 10: The invalid sha1 pointer in cache-tree seemed like it was from a (now outdated) index file (source). So I killed it and reset the repo.

第 10 步：缓存树中无效的 sha1 指针似乎来自（现已过时）索引文件（源）。所以我杀死了它并重置了回购。

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Step 11: Looking at the fsck again...

第 11 步：再次查看 fsck...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

The dangling blobs are not errors. I'm not concerned with master.u1conflict, and now that it is working I don't want to touch it anymore!

在晃来晃去斑点不是错误。我不关心 master.u1conflict，现在它正在工作，我不想再碰它了！

Step 12: Catching up with my local edits:

第 12 步：赶上我的本地编辑：

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

So hopefully that can be of some use to people in the future. I'm glad it worked.

所以希望这对未来的人们有用。我很高兴它奏效了。

回答by Martin Tajur

The git object files have gone corrupt (as pointed out in other answers as well). This can happen during machine crashes, etc.

git 对象文件已损坏（正如其他答案中所指出的那样）。这可能发生在机器崩溃等期间。

I had the same thing. After reading the other top answers here I found the quickest way to fix the broken git repository with the following commands (execute in the git working directory that contains the .gitfolder):

我有同样的事情。在阅读了此处的其他最佳答案后，我找到了使用以下命令修复损坏的 git 存储库的最快方法（在包含该.git文件夹的 git 工作目录中执行）：

(Be sure to back up your git repository folder first!)

（请务必先备份您的 git 存储库文件夹！）

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

This will first remove any empty object filesthat cause corruption of the repository as a whole, and then fetch down the missing objects(as well as latest changes) from the remote repository, and then do a full object store check. Which, at this point, should succeed without any errors (there may be still some warnings though!)

这将首先删除导致整个存储库损坏的所有空对象文件，然后从远程存储库中提取丢失的对象（以及最新更改），然后进行完整的对象存储检查。在这一点上，应该成功而没有任何错误（尽管可能仍然有一些警告！）

PS. This answer suggests you have a remote copy of your git repository somewhere (e.g. on GitHub) and the broken repository is the local repository that is tied to the remote repository which is still in tact. If that is not the case, then do not attempt to fix it the way I recommend.

附注。这个答案表明您在某处（例如在 GitHub 上）有一个 git 存储库的远程副本，而损坏的存储库是与远程存储库相关联的本地存储库，该存储库仍然完好无损。如果不是这种情况，那么不要尝试按照我推荐的方式修复它。

回答by Simone Gianni

I solved this removing the various empty files that git fsck was detecting, and then running a simple git pull.

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

I find it disappointing that now that even filesystems implement journaling and other "transactional" techniques to keep the fs sane, git can get to a corrupted state (and not be able to recover by itself) because of a power failure or space on device.

我发现令人失望的是，即使文件系统实现了日志和其他“事务”技术来保持 fs 正常，由于电源故障或设备上的空间，git 可能会进入损坏状态（并且无法自行恢复）。

回答by marlo

This error happens to me when I am pushing my commit and my computer hangs. This is how I've fix it.

当我推送提交并且我的计算机挂起时，我会发生此错误。这就是我修复它的方式。

---

---

Steps to fix

修复步骤

git status

show the empty/corrupt object file

显示空/损坏的目标文件

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

remove it

去掉它

git status

I got fatal: bad object HEADmessage

我收到fatal: bad object HEAD消息

rm .git/index

I remove the indexfor the reset

我删除index重置

git reset

fatal: Could not parse object 'HEAD'.

致命：无法解析对象“HEAD”。

git status
git pull

just to check whats happening

只是为了检查发生了什么

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

prints the last 2 lines tail -n 2of log branch to show my last 2 commit hash

打印tail -n 2日志分支的最后 2 行以显示我的最后 2 行commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

I pick the last commit hash

我选最后一个 commit hash

git status

shows all my file as deletedbecause i removed the .git/indexfile

显示我的所有文件，deleted因为我删除了.git/index文件

git reset

continue to the reset

继续重置

git status

verify my fix

验证我的修复

---

---

Note:The steps starts when I landed on this question and used the answers as reference.

注意：当我遇到这个问题并使用答案作为参考时，这些步骤就开始了。

回答by Nicolas

I just had the same issue : after pulling the distant repository, when I did a git status I got : "error: object file (...) is empty" "fatal: loose object (...) is corrupted"

我刚刚遇到了同样的问题：在拉出远程存储库后，当我执行 git status 时，我得到：“错误：目标文件（...）为空”“致命：松散的对象（...）已损坏”

The way I resolved this was to :

我解决这个问题的方法是：

1. git stash
2. removing git file in error (not sure that is necessary)
3. git stash clear

1. 混帐
2. 删除错误的 git 文件（不确定是否有必要）
3. git stash 清除

I dont know exactly what things happened, but that instructions seemed to make everything clean.

我不知道到底发生了什么事，但那个指示似乎让一切都变得干净了。

回答by haoqiang

Because I have to reboot my VM regularly, so somehow this problem happens to me very often. After few times of it, I realized I cannot repeat the process described by @Nathan-Vanhoudnos every time this happens, though it always works. Then I figured out the following faster solution.

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

Step 1

第1步

Move your entire repo to another folder.

将整个 repo 移动到另一个文件夹。

mv current_repo temp_repo

Step 2

第2步

Clone the repo from origin again.

再次从 origin 克隆 repo。

git clone source_to_current_repo.git

Step 3

第 3 步

Remove Everythingunder the new repo except the .gitfolder.

删除新仓库下的所有内容，除了.git文件夹。

Step 4

第四步

Move Everythingfrom the temp_repoto the new repo exceptthe .gitfolder.

将一切从temp_repo到新的回购只是在git的文件夹。

Step 5

第 5 步

Remove the temp_repo, and we are done.

删除temp_repo，我们就完成了。

After few times, I'm sure you can do this procedures very quickly.

几次之后，我相信你可以很快地完成这个过程。

回答by cyberfranco

1. mv your folder app to make backup, i.e. mvapp_folder app_folder_bk (it is like a git stash)
2. git clone your_repository
3. Finally,. Open a merge tool (I use meld diff viewer linux or Winmerge Windows) and copy the changes from right(app_folder_bk) to left( new app_folder) (it is like a git stash apply).

1. mv 您的文件夹应用程序进行备份，即mvapp_folder app_folder_bk （它就像一个git stash）
2. git clone your_repository
3. 最后，。打开合并工具（我使用 meld diff viewer linux 或 Winmerge Windows）并将更改从右侧（app_folder_bk）复制到左侧（ new app_folder）（就像git stash apply）。

That's all. Maybe it is not the best way, but I think it is so practical .

就这样。也许这不是最好的方法，但我认为它非常实用。

回答by androidevil

In my case, this error occurred because I was typing the commit message and my notebook turned off.

就我而言，发生此错误是因为我正在输入提交消息而我的笔记本已关闭。

I did these steps to fix the error:

我做了以下步骤来修复错误：

• git checkout -b backup-branch# Create a backup branch
• git reset --hard HEAD~4# Reset to the commit where everything works well. In my case, I had to back 4 commits in the head, that is until my head be at the point before I was typing the commit message. Before doing this step, copy the hash of the commits you will reset, in my case I copied the hash of the 4 last commits
• git cherry-pick <commit-hash># Cherry pick the reseted commits (in my case are 4 commits, so I did this step 4 times) from the old branch to the new branch.
• git push origin backup-branch# Push the new branch to be sure everything works well
• git branch -D your-branch# Delete the branch locally ('your-branch' is the branch with problem)
• git push origin :your-branch# Delete the branch from remote
• git branch -m backup-branch your-branch# Rename the backup branch to have the name of the branch that had the problem
• git push origin your-branch# Push the new branch
• git push origin :backup-branch# Delete the backup branch from remote

• git checkout -b backup-branch# 创建一个备份分支
• git reset --hard HEAD~4# 重置到一切正常的提交。在我的情况下，我必须在头脑中支持 4 次提交，直到我的头脑在我输入提交消息之前。在执行此步骤之前，复制您将重置的提交的哈希值，在我的情况下，我复制了最后 4 个提交的哈希值
• git cherry-pick <commit-hash># Cherry 选择从旧分支到新分支的重置提交（在我的例子中是 4 次提交，所以我做了 4 次此步骤）。
• git push origin backup-branch# 推送新分支以确保一切正常
• git branch -D your-branch# 在本地删除分支（'your-branch' 是有问题的分支）
• git push origin :your-branch# 删除远程分支
• git branch -m backup-branch your-branch# 将备份分支重命名为出现问题的分支的名称
• git push origin your-branch# 推送新分支
• git push origin :backup-branch# 从远程删除备份分支

回答by Gui-yi

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

resolve my problem

解决我的问题

回答by germanyDevelops

I run into this problem a lot with virtual machines.

我在虚拟机上经常遇到这个问题。

For me the following works:

对我来说，以下工作：

cd /path/to/your/project
rm -rf .git

If you want to save yourself some downloads - go in your file explorer and delete all files in the folder that are already committed and leave in your /vendor and /node_modules (I work with composer and npm) folders.

如果您想为自己保存一些下载 - 进入您的文件资源管理器并删除文件夹中已提交的所有文件，并保留在您的 /vendor 和 /node_modules（我使用 composer 和 npm）文件夹中。

then just create a new repo

然后只需创建一个新的回购

git init

add your remote

添加您的遥控器

git remote add origin ssh://[email protected]/YourUsername/repoName.git

and fetch the branch / all of it

并获取分支/所有

git fetch origin somebranch

and check it out

并检查出来

git checkout somebranch

then you should be at the point before the error.

那么你应该在错误之前的点。

Hope this helps.

希望这可以帮助。

Regards.

问候。