git-fsck分段错误目录

我在Rubymine中使用git。在另一次提交之后，我打开git push窗口，看到

对象文件。git/object/55/4d…e6是空的，无法读取..

而不是提交名称

运行

git fsck-full

可以得到以下信息：

分段错误目录：33%（85/256）

我能在这里做些什么吗？

Git 2.25（2020年第1季度）应该解决一个可能的

Git fsck

segfault原因。
该命令在对象解析和低级对象访问（正在修复）过程中积累了一些粗糙的代码和逻辑

参见，，，，，（2019年10月18日）和（2019年10月25日）的作者。
（于2019年12月1日合并）

：将

lookup\u commit（）

失败视为解析错误 签字人：杰夫·金

在解析提交的父对象时，如果我们能够解析实际的oid，但是

lookup\u commit（）

失败（因为我们以前在这个过程中将其视为不同的对象类型），那么我们会自动忽略父对象，并且不会向调用方报告任何错误

调用方无法知道发生了什么，因为即使是空的父列表也是有效的解析结果。因此，有可能欺骗我们的“

rev list

”连接检查以接受损坏的对象集

这导致：

：将

NULL

标记指针视为分析错误 签字人：杰夫·金

解析标记时，如果类型不匹配（例如，标记声称将对象

X

作为提交，但我们以前在同一过程中将

X

视为blob），我们可能会得到一个

NULL

“taged”字段，但我们不会向调用方指示解析失败

这与上一次提交中讨论的情况类似，在这种情况下，提交可能会以一个

NULL

树字段结束：虽然对于想要忽略损坏对象的调用方来说稍微方便一些，但这意味着普通调用方必须显式处理这种情况（而不仅仅依赖解析返回的代码）。
而大多数都没有，这导致了segfault修复，如中所列（“使用

get\u taged\u oid（）

”，2019-09-05，Git v2.24.0-rc0——中所列）

让我们更集中地解决这个问题，从解析本身返回一个错误代码，大多数调用方都已经注意到了（有冒险精神的调用方可以忽略错误并继续查看结构）

这也涵盖了标记包含一个无意义的“type”字段的情况（在这里，我们生成了一个用户可见的错误，但仍然向调用者返回了success；现在，我们将生成一个稍微好一点的消息并返回一个错误）

作为更好的错误消息的一部分：

• 不要再犯错误了
• yyy中指向“

  xxx

  ”的错误标记指针
• 或：在

  yyy

---

Git一直在打印

检查对象目录：

和那个百分比，然后Git本身就坏了。shell在检查对象目录的上方打印了

分段错误

，这就是在终端窗口中留下的

分段错误目录。不幸的是，segfault表明Git本身有一个bug。您可以做的是将源代码下载到Git，编译并调试它。。。（或者尝试不同版本的Git）