由于缺少对象导致Git损坏，我该怎么办？

Question

我刚刚想在另一台远程服务器上克隆一个存储库，但是遇到了问题：

git clone [e-mail]:blah/blah/docs.git
Cloning into docs...
remote: Counting objects: 343, done.
remote: error: unable to find 14f87a739828e4d489b0310a51e057b30333926e
remote: Compressing objects: 100% (325/325), done.
error: git upload-pack: git-pack-objects died with error.   
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: fatal: unable to read 14f87a739828e4d489b0310a51e057b30333926e
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

我进行了一些研究并发现了 git fsck，这是它的输出：

$ git fsck --full
error: sha1 mismatch 14f87a739828e4d489b0310a51e057b30333926e

error: 14f87a739828e4d489b0310a51e057b30333926e: object corrupt or missing
missing blob 14f87a739828e4d489b0310a51e057b30333926e

所有其他遇到类似问题的人都遇到了链接失效或类似的问题。我在 Git 中还很新，有人知道如何解决这个问题吗？

我仍然可以将代码推送到我的中央远程仓库，但无法克隆它。

14f87a739828e4d489b0310a51e057b30333926e 是存储库根目录中的一个 Markdown 文件。我尝试删除此文件并将更改推送到服务器，但没有成功。

---

编辑： 是否可能从另一个存储库导入 git 历史记录？我想我可以启动一个新的存储库，将我的文件复制到其中，然后导入提交历史记录。

- Cobby

Answer 1

这里有一个与之类似的问题，提供了非常详细的解决方案：Github Repo Corruption - Sha1 Collision

- ssmir

---

我已经阅读过，他有破损的链接问题，而我没有。 - Cobby

@Cobby 你也可以尝试从 https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F 中使用 B) 来定位损坏的文件。 - ssmir

Answer 2

如果只有一个单独的文件且尚未打包，则您应该能够在本地存储库中的 .git/objects/14/f87a739828e4d489b0310a51e057b30333926e 找到它。您可以将这些文件复制到服务器上相应的存储库目录中。

如果已经打包，您应该能够使用 git unpack-objects 在 .git/objects/pack/ 中的其中一个打包文件中进行解包。之后，复制到服务器的操作与上述相同。

- Koraktor

---

我没有/14/f887a7..这个东西。 有一个包，但是当我解压它时，没有新的对象文件夹被创建……只有两个（01和c7）。虽然它说正在工作中 Unpacking objects: 100% (346/346), done.。 - Cobby

@Cobby：更好的选择，无论对象是否被打包，都可以在这里详细了解：https://dev59.com/eYLba4cB1Zd3GeqPkdwg#25527813 - CharlesB

Answer 3

简单的推送操作无法解决这个问题，因为Git会认为它已经拥有了所有需要的对象，因为它看到了引用损坏文件的提交。

你是否有另一个存储库包含该项目，并且没有fsck报告任何问题（并且包含相关文件）？例如，在您的本地机器上？那么您应该尝试：

1. 将损坏的存储库放在一边。
2. 克隆好的存储库到原来的位置。
3. 从其他存储库或旧存储库中推送旧存储库具有的任何分支。

由于这种类型的错误意味着磁盘上的文件已损坏，建议您对文件系统、磁盘和内存进行彻底检查（当Git保存数据时，数据可能在内存中损坏）。

注意：虽然所有磁盘都至少具有一些校验和，但大多数内存芯片根本没有校验和，因此内存故障比磁盘故障更容易被忽略。memtest86+是检查内存的好方法。

- Jan Hudec

---

关于内存“校验和”的一个侧面说明，与问题/答案无关：服务器通常使用带有ECC的RAM芯片。 - Koraktor

不仅服务器支持ECC。例如，带有XEON处理器的工作站主板也支持ECC RAM。尽管它的性能略低于非ECC，但我仍然更喜欢它在数据完整性和纠错方面提供的安全性。在我的情况下，我使用一台配备XEON和6 * 2GB ECC RAM的ASUS P6B WS三通道配置，性能非常完美。 - Lucero

@Koraktor 嗯，是的也不是。它们与错误恢复无关，但这种类型的错误通常表示硬件问题以及该问题可能出现的位置是相关的。 - Jan Hudec

我没有其他副本存储库。有我的本地版本和Codebase版本。我有一个想法，更新我的问题。 - Cobby

哦，我的本地版本库实际上存储在NAS上。 - Cobby

我已经为我的服务器购买了新的硬盘驱动器。我在/var/log/kern.log中看到了各种I/O错误。OEI！ - Melroy van den Berg