git Github Repo 损坏 - Sha1 冲突

Github Repo Corruption - Sha1 Collision

提问by saalon

Yesterday one of my team's checkins corrupted our github repo. On github, they were showing this error:

昨天，我团队的一个签入损坏了我们的 github 存储库。在github上，他们显示了这个错误：

$ git fsck
error: sha1 mismatch 87859f196ec9266badac7b2b03e3397e398cdb18

error: 87859f196ec9266badac7b2b03e3397e398cdb18: object corrupt or missing
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

When I tried to pull onto a different machine, I got this:

当我试图拉到另一台机器上时，我得到了这个：

Hyperion:Convoy-clone saalon$ git fsck
warning in tree 5b7ff7b4ac7039c56e04fc91d0bf1ce5f6b80a67: contains zero-padded file modes
warning in tree 5db54a0cdcd5775c09365c19c061aff729579209: contains zero-padded file modes
broken link from    tree 6697c12387f8909cfe7250e9d5854fd6713d25c1
              to    blob 87859f196ec9266badac7b2b03e3397e398cdb18
dangling tree 144becf61ae14cec34b6af1bd8a0cf4f00d346d1
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

(I get the zero-padded file warnings on both the offending machine and the second machine I pulled to. I get the broken link error only on the second machine).

（我在有问题的机器和我拉到的第二台机器上都收到了零填充的文件警告。我只在第二台机器上收到了断开的链接错误）。

I tracked down the blob to the specific file that's the problem, but after going through the Git FAQ's process on fixing a broken link error, I had no luck.

我将 blob 追踪到了问题所在的特定文件，但是在完成 Git FAQ 修复断开链接错误的过程后，我没有走运。

I went through Github's documentation and found a process to delete the master repo from github and repush from the offending machine. I tried this, but when I went to re-push the master branch, I got the following error:

我浏览了 Github 的文档，找到了一个从 github 删除主存储库并从违规机器重新推送的过程。我试过了，但是当我去重新推送master分支时，出现以下错误：

fatal: SHA1 COLLISION FOUND WITH 87859f196ec9266badac7b2b03e3397e398cdb18 !
error: unpack failed: index-pack abnormal exit

I've got an open ticket with Github but it's taking them forever to respond. Any idea what the problem might be? Is there a problem at Github that they need to fix, or is there something I can do to take care of this?

我有一个 Github 的公开票，但他们需要永远回应。知道可能是什么问题吗？Github 是否有他们需要修复的问题，或者我可以做些什么来解决这个问题？

采纳答案by saalon

After some back and forth with GitHub (and some troubleshooting help from ssmir), this problem is split between a thing I needed to solve and a thing Github needed to solve.

经过与 GitHub 的一些来回（以及来自 ssmir 的一些故障排除帮助），这个问题分为我需要解决的问题和 Github 需要解决的问题。

What needed to be solved on my end was this:

我最后需要解决的是：

Hyperion:Convoy-clone saalon$ git fsck
warning in tree 5b7ff7b4ac7039c56e04fc91d0bf1ce5f6b80a67: contains zero-padded file modes
warning in tree 5db54a0cdcd5775c09365c19c061aff729579209: contains zero-padded file modes
broken link from    tree 6697c12387f8909cfe7250e9d5854fd6713d25c1
              to    blob 87859f196ec9266badac7b2b03e3397e398cdb18
dangling tree 144becf61ae14cec34b6af1bd8a0cf4f00d346d1
missing blob 87859f196ec9266badac7b2b03e3397e398cdb18

If you notice, there's a broken link from a tree to a blob. What this is saying is that there's a folder that should have a file in it, but there's not actually a file in it. Someone added a file to their local repo and pushed it, but the file itself didn't end up in the remote repo. Now every time someone pulls down the repo themselves, they get the same broken git filesystem link.

如果您注意到，从树到 blob 的链接已断开。这就是说有一个文件夹应该有一个文件，但实际上里面没有文件。有人向他们的本地存储库添加了一个文件并将其推送，但该文件本身并没有出现在远程存储库中。现在，每次有人自己拉下 repo 时，他们都会得到同样损坏的 git 文件系统链接。

The instructions heredo a good job of explaining what to do if you get the problem, but in the midst of the actual crisis, I found the description a little lacking in context. It gave a clear list of steps but not a great idea of the why - at least, not for someone who's still a little new to Git.

该指令在这里做解释，如果你得到了什么问题做一个好工作，但在实际的危机中，我发现，缺乏上下文中的一点说明。它给出了一个清晰的步骤列表，但并没有很好地说明原因——至少，对于对 Git 还是有点陌生​​的人来说不是这样。

Basically, what you need to do is figure out what file that missing blob is, track down what computer checked it in last and go to work on their local repo. Their computer has both the SHA1 link to the file andthe contents of the file itself. Everyone else has a pile of broken.

基本上，您需要做的是找出丢失的 blob 是什么文件，追踪上次检查它的计算机并开始处理他们的本地存储库。他们的计算机既有SHA1链接到文件和文件本身的内容。其他人都有一堆破烂。

So first, we need to find out what blobs/files are in that tree. To do that, you use git ls-tree.

因此，首先，我们需要找出该树中的 blob/文件。为此，您可以使用 git ls-tree。

git ls-tree 6697c12387f8909cfe7250e9d5854fd6713d25c1

In my case, that listed only one file: the file that was corrupt. In your case, it might give a whole list of files, in which case what you need to do is match up the blob/file's SHA1 hash to the one mentioned in the broken link error. In my case, it was this:

就我而言，它只列出了一个文件：已损坏的文件。在您的情况下，它可能会提供完整的文件列表，在这种情况下，您需要做的是将 blob/文件的 SHA1 哈希与断开链接错误中提到的哈希匹配。就我而言，是这样的：

100644 blob 87859f196ec9266badac7b2b03e3397e398cdb18    short_description.html

Notice that it doesn't give you the directory the file is actually supposed to be in. That's kind of frustrating, but with a little detective work you can find it. The file might be uniquely named, in which case you can just do a find for the file name. Or you can look through your commit history and see when and where a file called short_description.html was placed.

请注意，它没有为您提供文件实际所在的目录。这有点令人沮丧，但您可以通过一些侦探工作找到它。该文件可能具有唯一名称，在这种情况下，您只需查找文件名即可。或者，您可以查看提交历史记录，查看放置名为 short_description.html 的文件的时间和位置。

Here's the part the GitFaq wasn't entirely clear on. They say to recreate the file, then run this command:

这是 GitFaq 不完全清楚的部分。他们说要重新创建文件，然后运行以下命令：

git hash-object -w db/content/page_parts/venues/86/short_description.html 

But what is that doing?

但那是在做什么？

Basically, when you run git hash-object is returns the sha1 hash for that file. And (and here's the important part) it creates a blob from the file, and a blob was just what we were missing. Here's the part it's not clear on, though: In order for this to work, the file needs to match exactly the file that initially caused the problem. In other words, if that short_description.html file had content in it, you can't just create a blank file and run hash-object. If you do, the blob's sha1 hash won't match the one git is missing, and that broken link will still be broken.

基本上，当您运行 git hash-object 时，会返回该文件的 sha1 哈希值。并且（这是重要的部分）它从文件中创建一个 blob，而 blob 正是我们所缺少的。不过，这是它不清楚的部分：为了使其正常工作，文件需要与最初导致问题的文件完全匹配。换句话说，如果该 short_description.html 文件中包含内容，则不能只创建一个空白文件并运行 hash-object。如果这样做，blob 的 sha1 哈希将与丢失的 git 不匹配，并且该断开的链接仍将断开。

This is why you need to be on the offending machine's repo. Everyone else has a link but not file and no blob. The offending machine (hopefully) still has the original file. In my case, they didn't have the original file (in my flailing, it had been deleted inadvertently), but when I looked at their commit history on their box, the diff contained the content of the file that had been committed but never made it to github. I copied that out, recreated the file and ran hash-object. The next time I ran git fsck, the broken link was gone.

这就是为什么你需要在违规机器的回购中。其他人都有链接，但没有文件，也没有 blob。有问题的机器（希望）仍然有原始文件。就我而言，他们没有原始文件（在我的混乱中，它被无意中删除了），但是当我在他们的盒子上查看他们的提交历史时，差异包含已提交但从未提交的文件内容到了github。我复制了它，重新创建了文件并运行了 hash-object。下次我运行 git fsck 时，断开的链接消失了。

One note: technically, this problem can be fixed on someone else's repo, provided you can recreate the missing file. In my case, I actually had the file created on the offending machine, but had it e-mailed to me and fixed the problem in a clean repo on a different system. The important thing is recreating the file exactly so it generates the same sha1 hash that the repo is missing.

一个注意事项：从技术上讲，只要您可以重新创建丢失的文件，就可以在其他人的存储库上修复此问题。就我而言，我实际上在有问题的机器上创建了文件，但是它通过电子邮件发送给我并在不同系统上的干净存储库中修复了问题。重要的是完全重新创建文件，以便它生成与 repo 缺少的相同的 sha1 哈希。

As for the SHA1 collision problem I got when I tried to push to github? This ugly sucker?

至于我在尝试推送到 github 时遇到的 SHA1 冲突问题？这个丑陋的吸盘？

fatal: SHA1 COLLISION FOUND WITH 87859f196ec9266badac7b2b03e3397e398cdb18 !
error: unpack failed: index-pack abnormal exit

That was a problem in github's side that they needed to fix.

这是 github 方面的一个问题，他们需要解决。

回答by phorgan1

Just a reminder. A small likelihood of something happening is not the same as it not being able to happen. You canget hash collisions with git's use of sha-1. Once you have two files that collide, the likelihood becomes 100%. At that point, there's slim consolation from the theoretical likelihood. Add a space to one and you'll be fine though.

只是提醒。某事发生的小可能性与它不可能发生是不一样的。您可以通过 git 使用 sha-1来获得哈希冲突。一旦有两个文件发生冲突，可能性就会变为 100%。在这一点上，理论上的可能性有一点点安慰。给一个加一个空格，你会没事的。

回答by depperm

I ran into the same issue and ran:

我遇到了同样的问题并跑了：

git prune  
git gc  

which mentioned

其中提到

error: bad ref for refs/remotes/origin/ticketName

错误：refs/remotes/origin/ticketName 的错误引用

so I removed the reference and that fixed the issue:

所以我删除了参考并解决了问题：

rm .git/refs/remotes/origin/ticketName

回答by Tin Torres

This happened to me recently on "git pull" from AWS Git server. The commands below fix the issue. thanks

我最近在 AWS Git 服务器的“git pull”上发生了这种情况。下面的命令解决了这个问题。谢谢

git prune git gc

git 修剪 git gc