git“松散的对象......已损坏” - 我丢失了哪些数据？

git "loose object ... is corrupt" - what data have I lost?

提问by stripybadger

I have made a few commits to a local branch, then I tried to do git fetch. It failed with the following errors:

我已经向本地分支提交了一些提交，然后我尝试执行git fetch. 它失败并出现以下错误：

fatal: loose object 7b36029a951eacd979d24e993e020c4d018ca265 (stored in .git/objects/7b/36029a951eacd979d24e993e020c4d018ca265) is corrupt
fatal: unpack-objects failed

Running git fsckjust shows the same as the first line. Any command that would actually commit or push my changes seems to fail for the same reason.

运行git fsck只显示与第一行相同的内容。由于同样的原因，任何实际提交或推送我的更改的命令似乎都失败了。

The file appears to just contain a load of zeros. I've seen how to fix GIT error: object file is empty?in which someone reports success resolving this by deleting the file that is corrupt.

该文件似乎只包含大量零。我已经看到如何修复 GIT 错误：目标文件为空？其中有人报告通过删除损坏的文件成功解决了这个问题。

My question is: if I go through deleting every file that it says is corrupt, what will I lose? Will I actually lose any commits?

我的问题是：如果我删除它说已损坏的每个文件，我会丢失什么？我真的会丢失任何提交吗？

Note I'm not sure how I got into this state, though it happened after my pc blue-screened, so maybe that caused it.

请注意，我不确定我是如何进入这种状态的，尽管它发生在我的电脑蓝屏之后，所以可能是这导致了它。

回答by jwg

I fixed this problem on my git repository, where I believe it was caused by a dodgy filesystem (on a Linux virtual machines hosted on Windows) acting up on a hard reset.

我在我的 git 存储库中修复了这个问题，我认为它是由一个不可靠的文件系统（在 Windows 上托管的 Linux 虚拟机上）导致的硬重置。

I started out in the same place as you, with:

我和你在同一个地方开始，有：

Hyman@machine:~/git/cs$ git status
error: object file .git/objects/2e/f529faaaed03b2384b9f4d49a2ea95d7833894 is empty
error: object file .git/objects/2e/f529faaaed03b2384b9f4d49a2ea95d7833894 is empty
fatal: loose object 2ef529faaaed03b2384b9f4d49a2ea95d7833894 (stored in .git/objects/2e/f529faaaed03b2384b9f4d49a2ea95d7833894) is corrupt

Before doing anything, I backed up the whole tree by making a recursive copy of it into another folder. Do this.

在做任何事情之前，我通过将它的递归副本复制到另一个文件夹来备份整个树。做这个。

Then I forcibly removed the object which was corrupt:

然后我强行删除了损坏的对象：

Hyman@machine:~/git/cs$ rm .git/objects/2e/f529faaaed03b2384b9f4d49a2ea95d7833894 
rm: remove write-protected regular empty file ‘.git/objects/2e/f529faaaed03b2384b9f4d49a2ea95d7833894'? y

I then got a different problem which prevented me from running any git commands:

然后我遇到了一个不同的问题，导致我无法运行任何 git 命令：

Hyman@machine:~/git/cs$ git status
fatal: bad object HEAD

Instead of doing a checkoutas some people recommend to get HEADback to a good state, I did reset. checkoutchanges both the state of your tree and the branch that you are on. reset(without --hard) changes the branch that you are on, but doesn't change any of the files. I wanted to keep all the files I had in their current state, all the more so since they are the only record of my recent commits (since the branch that I am on, has some problem, and can't be logged).

我没有checkout像某些人建议的那样做以HEAD恢复良好状态，而是做了reset。checkout改变树的状态和你所在的分支。reset(without --hard) 更改您所在的分支，但不更改任何文件。我想保留我拥有的所有文件的当前状态，更重要的是因为它们是我最近提交的唯一记录（因为我所在的分支存在一些问题，并且无法记录）。

When I last could use git, I was on a feature branch, call it feature_foo. I couldn't reset to feature_foosince it pointed to the deleted commit 2ef529fa..I reset to master. I believe it doesn't matter where you reset to, any other branch should do.

当我最后一次可以使用 git 时，我在一个功能分支上，称之为feature_foo. 我无法重置为，feature_foo因为它指向2ef529fa..我重置为的已删除提交master。我相信您重置到哪里并不重要，任何其他分支都应该这样做。

Hyman@machine:~/git/cs$ git reset master
Unstaged changes after reset:
M   a/bunch/of_changes
M   more/changes
error: Trying to write ref ORIG_HEAD with nonexistent object 2ef529faaaed03b2384b9f4d49a2ea95d7833894
error: Cannot update the ref 'ORIG_HEAD'.

Now I am on master, but with the same file tree that I had before. Since feature_foowas quite different from master, I see loads of unstaged, uncommitted changes. This is normal. I think the message about ORIG_HEADjust means that git records my previous location somewhere, and right now it's not happy because my previous location is the deleted commit.

现在我在master，但使用与我以前相同的文件树。由于feature_foo与 完全不同master，我看到了大量未暂存、未提交的更改。这是正常的。我认为关于消息ORIG_HEAD只是意味着 git 在某处记录了我以前的位置，现在它不高兴，因为我以前的位置是已删除的提交。

Now that I have a proper HEAD, I can do git reflog:

现在我有了一个合适的HEAD，我可以做git reflog：

Hyman@machine:~/git/cs$ git reflog
61ac654 HEAD@{0}: commit: Commit message from a commit I did earlier
f9a1ce9 HEAD@{1}: commit: Another commit message
b26a6e9 HEAD@{2}: commit: Yet another commit message

Here I see that all the commits I did on the feature branch before losing my work are still there. I think that only the most recent one, 2ef529fa..was lost of course. I would like to reset to HEAD@{1}to be back on a branch with these commits.

在这里，我看到我在失去工作之前在功能分支上所做的所有提交仍然存在。我认为只有最近的一个，2ef529fa..当然丢失了。我想重置为HEAD@{1}回到具有这些提交的分支上。

Hyman@machine:~/git/cs$ git reset HEAD@{1}
fatal: Log .git/logs/HEAD is corrupt.

So I open this file to edit it:

所以我打开这个文件进行编辑：

Hyman@machine:~/git/cs$ vim .git/logs/HEAD

This file looks like a bunch of SHA1s and commit messages, until the last few lines:

这个文件看起来像一堆 SHA1 和提交消息，直到最后几行：

b26a6e99762e703914dc3749fe136d99e100ac74 f9a1ce9c9eaa54b51aa29efdeafec023202de470 Hyman <[email protected]> 1434447540 +0100  commit: Another commit message
f9a1ce9c9eaa54b51aa29efdeafec023202de470 420ded21ffed88a2865cc0adaf3f54b0b44864e2 Hyman <[email protected]> 1434449503 +0100  commit: Commit message from a commit I did earlier
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@2ef529faaaed03b2384b9f4d49a2ea95d7833894 53b404d482a426046f2de6484b8855d1154b7fca Hyman <[email protected]> 1434465895 +0100  reset: moving to master

In other words, I see the same valid commits in the reflog, then a bunch of garbage, then a commit which shows me resetting to masterFROM the invalid commit (scroll right to see it).

换句话说，我在 reflog 中看到相同的有效提交，然后是一堆垃圾，然后是一个提交，它显示我重置为master无效提交（向右滚动以查看它）。

I delete all the garbage and everything past it, then save the file. Now I can look at the reflog again:

我删除了所有垃圾和过去的所有内容，然后保存文件。现在我可以再次查看 reflog：

Hyman@machine:~/git/cs$ git reflog
61ac654 HEAD@{0}: commit: Commit message from a commit I did earlier
f9a1ce9 HEAD@{1}: commit: Another commit message
b26a6e9 HEAD@{2}: commit: Yet another commit message

Now, the abbreviated SHA1 from the first line, 61ac654, seems to point to master. This is confirmed by me looking further down the reflog and seeing the same SHA1 appear in other places, when I was on master. Furthermore, doing git reset HEAD@{0}doesn't do anything at all. But if I do:

现在，第一行的缩写 SHA161ac654似乎指向master. 当我在master. 此外，做git reset HEAD@{0}根本没有任何作用。但如果我这样做：

Hyman@machine:~/git/cs$ git reset HEAD@{1}
Unstaged changes after reset:
M   just/a/few_changes

The small number of unstaged changes shows me that my file tree is now very close to what I have committed in Git. Doing git logconfirms that I have all the commits I saw in the reflog in my history now, except for the first one. So I just have to re-commit this commit, and the naughty one 2ef529fto get exactly back to where I started!

少量未暂存的更改表明我的文件树现在非常接近我在 Git 中提交的内容。做git log确认我现在拥有我在历史记录中的 reflog 中看到的所有提交，除了第一个。所以我只需要重新提交这个提交，顽皮的那个2ef529f就回到我开始的地方！

This took some figuring out, but meant I didn't lose the dozen or so commits since my last push.

这需要一些弄清楚，但这意味着自上次推送以来，我并没有丢失十几个提交。

回答by AndersLindas

In our case the remote git had a corrupted file blob ~28mb. This file should have been ~32mb but somehow became corrupted.

在我们的例子中，远程 git 有一个损坏的文件 blob ~28mb。这个文件应该是 ~32mb 但不知何故损坏了。

Solution was to copy the blob file from the computer that made the commit, and overwrite the corrupted file on the remote git repository.

解决方案是从进行提交的计算机上复制 blob 文件，并覆盖远程 git 存储库上损坏的文件。

回答by daisura99

I faced a similar problem and followed @jwg solution but couldn't proceed at the git reflogstep.

我遇到了类似的问题并遵循了@jwg 解决方案，但无法继续执行该git reflog步骤。

git reflogproduced onlythe following:-

git reflog仅生产以下产品：-

1fd3a1d HEAD@{0}: reset: moving to develop

However, the result was that my git was not corrupt anymore and my code was still untouched after all the modifications. It's just that the changes are un-committedand all the commits I have made were missing.

然而，结果是我的 git 不再损坏，我的代码在所有修改后仍然没有受到影响。只是更改未提交并且我所做的所有提交都丢失了。

At this point, I could perform a git-commit -aand lose all the commits but still maintain the latest code.

此时，我可以执行 agit-commit -a并丢失所有提交，但仍保留最新代码。

Then, I noticed a branch tempwas created. Inside it was a laterversion of my code, though not the latest. As an illustration:-

然后，我注意到temp创建了一个分支。里面是我的代码的更新版本，虽然不是最新的. 举例说明：-

current branch- feature/feature1 (now contains my latest code, but missing most commits)

当前分支- 功能/功能 1（现在包含我的最新代码，但缺少大多数提交）

another branch- temp (does not contain latest code, but has more commits than the current branch

另一个分支- temp（不包含最新代码，但比当前分支有更多的提交

So I proceeded by git commit -amy current branch and then git rebase temp, fixed some conflicts and done! In the end, I still lost somecommits but at least the code is the latest.

所以我继续git commit -a我当前的分支，然后git rebase temp修复了一些冲突并完成了！最后，我仍然丢失了一些提交，但至少代码是最新的。

Edit

编辑

turns out I did not have the latest working code, so all I managed to save is some commits. I restored the files with a backup.

结果我没有最新的工作代码，所以我设法保存的只是一些提交。我用备份恢复了文件。

回答by Mohammed Shareef C

This happens when some file(s) in .gitfolder in the repository is corrupted. Most probably you may not have lost any of your data. File corruption can be caused due to a unexpected power failure. If it is the case, there is a chance for data lose.

当.git存储库中文件夹中的某些文件损坏时会发生这种情况。您很可能没有丢失任何数据。意外断电可能会导致文件损坏。如果是这种情况，则有可能丢失数据。

In my case, the reason was power failure. I just cloned the remote repoto another location and copied the whole .gitfolderto my existing local repo. It solved the problem and none of my data was lost.

就我而言，原因是电源故障。我只是将远程仓库克隆到另一个位置，并将整个.git文件夹复制到我现有的本地仓库。它解决了问题，我的数据没有丢失。

回答by Agis

An easy fix is to move the old repository somewhere else and reclone it:

一个简单的解决方法是将旧存储库移动到其他地方并重新克隆它：

$ cd ..
$ mv <repo-name> <repo-name>-original
$ git clone <url> <repo-name>

If there are stuff lost there are ways to retrieve them from the old repository, but first try to reclone it.

如果丢失了东西，有办法从旧存储库中检索它们，但首先尝试重新克隆它。