我如何处理损坏的git对象文件？ [英] How do I deal with corrupted git object files?

问题描述

当我接近配额时，我做了一个git pull，结果（所以我认为）得到了一个损坏的文件：

  $ git pull 
 walk dffbfa18916a9db95ef8fafc6d7d769c29a445aa 
致命错误：object d4a0e7599494bfee2b5351113895b43c351496b3已损坏
 
 $ git fsck --full 
坏sha1文件：.git / objects / 66 / b55c76947b1d38983e0944f1e6388c86f07a1b.temp 
致命的：对象d4a0e7599494bfee2b5351113895b43c351496b3损坏
 
 $ git的猫文件-t d4a0e7599494bfee2b5351113895b43c351496b3 
错误：无法找到d4a0e7599494bfee2b5351113895b43c351496b3 
致命的：git的CAT-文件d4a0e7599494bfee2b5351113895b43c351496b3：坏文件
  

我怎样才能解决这个问题？

.git / objects / 66 / b55c76947b1d38983e0944f1e6388c86f07a1b.temp为零字节;删除它没有任何解决我的问题（相同的错误）。

解决方案

通常，修复损坏的对象可能会非常困难。但是，在这种情况下，我们确信问题是中止传输，这意味着对象位于远程存储库中，所以我们应该能够安全地删除我们的副本，并让git从远程正确地获取它，这次。

临时目标文件，大小为零，显然可以被删除。这不会对我们有任何好处。引用它的腐败对象 d4a0e75 ... 是我们真正的问题。它可以在 .git / objects / d4 / a0e75 ... 中找到。正如我上面所说，删除是安全的，但为了以防万一，请先备份它。

此时，新鲜的 git pull 应该成功。

...假设它首先取得成功。在这种情况下，似乎一些本地修改阻止了尝试的合并，所以 stash ， pull ，隐藏流行的顺序。然而，这可能发生在任何合并中，并且与被破坏的对象没有任何关系。 （除非有必要进行索引清理，并且存储在这个过程中执行了这个操作，但我不这么认为）。

I did a git pull when I was near my quota, and as a result (so I think), got a corrupted file:

$ git pull
walk dffbfa18916a9db95ef8fafc6d7d769c29a445aa
fatal: object d4a0e7599494bfee2b5351113895b43c351496b3 is corrupted

$ git fsck --full
bad sha1 file: .git/objects/66/b55c76947b1d38983e0944f1e6388c86f07a1b.temp
fatal: object d4a0e7599494bfee2b5351113895b43c351496b3 is corrupted

$ git cat-file -t d4a0e7599494bfee2b5351113895b43c351496b3
error: unable to find d4a0e7599494bfee2b5351113895b43c351496b3
fatal: git cat-file d4a0e7599494bfee2b5351113895b43c351496b3: bad file

How can I solve this corruption?

.git/objects/66/b55c76947b1d38983e0944f1e6388c86f07a1b.temp was zero bytes; deleting it did nothing to solve my problem(same errors).

解决方案

In general, fixing corrupt objects can be pretty difficult. However, in this case, we're confident that the problem is an aborted transfer, meaning that the object is in a remote repository, so we should be able to safely remove our copy and let git get it from the remote, correctly this time.

The temporary object file, with zero size, can obviously just be removed. It's not going to do us any good. The corrupt object which refers to it, d4a0e75..., is our real problem. It can be found in .git/objects/d4/a0e75.... As I said above, it's going to be safe to remove, but just in case, back it up first.

At this point, a fresh git pull should succeed.

...assuming it was going to succeed in the first place. In this case, it appears that some local modifications prevented the attempted merge, so a stash, pull, stash pop was in order. This could happen with any merge, though, and didn't have anything to do with the corrupted object. (Unless there was some index cleanup necessary, and the stash did that in the process... but I don't believe so.)

这篇关于我如何处理损坏的git对象文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！