【问题标题】:How to fix corrupted git repository - "git fsck" reports "warning in tree [hash]: contains entries pointing to null sha1"如何修复损坏的 git 存储库 - “git fsck”报告“树 [hash] 中的警告:包含指向 null sha1 的条目”
【发布时间】:2015-08-11 06:57:51
【问题描述】:

概述:

我无法成功地将我们的 repo 中的更改拉取到我们的生产服务器。

在我的 repo 上运行“git fsck”返回了 5 个相同错误的实例:

warning in tree [hash]: contains entries pointing to a null sha1

我们的所有版本的 repo 都存在该错误,包括托管在 bitbucket 上的版本。

我和我的同事都对我们非常希望保留的本地版本的存储库进行了未推送和未提交的更改。

我已经尝试通过 google、stackoverflow 和手册页来解决这个问题,但我找不到一个好的指南来解释正在发生的事情或如何解决问题。

在 GIT 方面,我和我的同事都是相对的菜鸟。我们已经掌握了基础知识,但还没有花时间研究低级命令。

如果能帮助我恢复我的存储库的完整性,我将不胜感激。

详细说明:

当我尝试将远程分支拉到我的生产服务器时,我的问题就开始了。它应该是对工作目录的简单更新,但我遇到了一些我不记得的模糊错误,发现我的工作目录已损坏。

Git 状态在合并失败后报告了大量未跟踪和修改的文件。我不知道如何用 git 命令解决问题,所以我手动操作文件系统来删除文件(但我没有触及 .git 目录中的任何内容)并将我的工作目录恢复到我的状态生产服务器将为我的网站提供服务而不会出错。

在我的 repo 上运行“git fsck”返回了 5 个相同错误的实例:

warning in tree [hash]: contains entries pointing to a null sha1

我运行了 git fsck:

  • 我的开发机器上的仓库
  • 我同事的开发机器
  • 来自 bitbucket 在 dev 和 prod 上的新克隆版本 repo

我尝试的所有内容都显示相同的警告。因此,无论问题是什么,它都存在于我们的所有版本的 repo 中。

调用“git ls-tree [树哈希报告错误]”会显示正常的目录打印输出以及错误的树哈希:

160000 commit 0000000000000000000000000000000000000000 [name of repo]

我找到的最接近解决方案的是这个 stackoverflow 帖子:How to remove an entry with null sha1 in a Git tree。但是,我无法真正理解这些步骤,并且剪切和粘贴命令无法解决我的问题。

我的问题:

  • 这些错误的真正含义是什么?他们有多严重?
  • 我们如何修复我们的 repo(如果可能,请为我们的菜鸟一步一步地进行)?
  • 我们应该在修复之前还是之后提交所有更改并将其推送到存储库?
  • 修复回购有什么影响?我们如何将修复分发到所有版本的存储库(例如开发机器和生产服务器)?
  • 是什么导致了这个错误,我们如何防止它再次发生?

【问题讨论】:

  • 原来我桌面上的 RAM 开始抛出错误(memtest86 失败)。我相信坏 RAM 损坏了我的 GIT 提交,当我推送更改时,一切都损坏了。

标签: git git-fsck


【解决方案1】:

这个问题很老了;不过,也许它可以帮助别人。

  • 这个错误可能意味着你曾经有过子模块,后来又去掉了它们,然后出了点问题。
  • 如何修复很大程度上取决于相关树木的具体外观。关键是要充分了解 git 内部结构,以便弄清楚该做什么。这实际上并不难,因为 git 的根源只有少数几个概念。查看https://git-scm.com/book/en/v2/Git-Internals-Git-Objects。您链接的问题的答案非常好。
  • 我会这样做:
    • 制作存储库的本地副本(使用您的操作系统文件工具,而不是 git),然后在副本中执行 git reset --hard,然后修复所有内容。
    • 将此固定存储库发送到新的远程,以便您的朋友可以使用它。
    • 你们俩都从原始存储库复制本地更改,再次使用cp,而不是 git。
    • 像往常一样提交、推送、拉取,直到这三个新存储库都正常。 - 扔掉旧的本地存储库,用git push --all --force 替换旧的遥控器。
  • 影响取决于实际维修的复杂程度。但它可能会与一个巨大的变基相媲美,即新的提交散列无处不在,git 为您提供“分歧分支”消息,中间有数百个提交。你不应该失去历史。我建议不要在新旧存储库之间推送/拉取/合并。
  • 原因可能是一些子模块的恶作剧,因为子模块是导致提交哈希出现在树中的一件事。为了避免......避免子模块?很难说。

【讨论】:

  • 感谢您的回答。我们最终确实通过编辑存储库来修复它(我不记得所有细节)。
猜你喜欢
  • 2013-09-11
  • 2012-01-06
  • 1970-01-01
  • 2016-05-01
  • 1970-01-01
  • 2010-12-05
  • 2020-04-08
  • 1970-01-01
  • 2012-05-27
相关资源
最近更新 更多