我在 Rubymine 中使用 git。在另一个提交后，我打开了 git 推送窗口并看到了object file .git/object/55/4d...e6 is emptyunable to read ....而不是提交名称。
运行git fsck -full给了我这个：Segmentation faultrectories: 33% (85/256)
我能在这里做些什么吗？
Git 2.25(2020 年第 1 季度)应该解决一个可能的git fsck段错误原因。
该命令在对象解析和低级对象访问方面积累了大量代码和逻辑，这些代码和逻辑正在修复。
请参阅提交 b2f2039、提交c5b4269、提交 103fb6d、提交 f648ee7、提交 cc57900、提交7854399、提交 b8b00f1、提交 6da40b2、提交3837025、提交 f597937、提交 5afc4b1、提交 82ef89b、提交 7339029、提交 d40bbc1、提交 a59cfb3、提交 23a173a、提交 2175a0c、提交 ec65231、提交 1de6007、提交 78d5014、提交 12736d2、提交 c78fe00(2019 年 10 月 18 日)和提交 228c78f(2019 年 10 月 25 日)(peff)。
(由 Junio C Hamano --gitster-- 合并于 提交 0e07c1c， 01 Dec 2019)
parse_commit_buffer()：将lookup_commit()失败视为解析错误签名者：杰夫·金
在解析提交的父级时，如果我们能够解析一个实际的 oid，但
lookup_commit()失败(因为我们之前在这个过程中将其视为不同的对象类型)，我们会静默地省略父级，并且不向调用方报告任何错误。调用方无法知道这种情况发生了，因为即使是空的父列表也是有效的解析结果。因此，有可能欺骗我们的"
rev-list"连接检查接受一组损坏的对象。
这导致：
parse_tag_buffer()：将标记指针视为NULL解析错误签名者：杰夫·金
解析标签时，当类型不匹配时，我们可能会得到一个
NULL"标记"字段(例如，标签声称指向对象X作为提交，但我们之前在同一进程中X视为 blob)，但我们不会以其他方式向调用方指示解析失败。这类似于上一个提交中讨论的情况，其中提交可能最终会得到一个
NULL树字段：虽然对于想要忽略损坏对象的调用者来说稍微方便一些，但这意味着普通调用者必须显式处理这种情况(而不仅仅是依赖解析的返回代码)。
大多数没有，导致段错误修复，如 c77722b3ea 中的修复("useget_tagged_oid()"，2019-09-05，Git v2.24.0-rc0 - 合并列在批次 #4 中)。让我们通过从解析本身返回错误代码来更集中地解决这个问题，大多数调用者已经注意到了(冒险的调用者可以自由地忽略错误并继续查看结构)。
这也涵盖了标签包含无意义的"type"字段的情况(在那里我们产生了一个用户可见的错误，但仍然向调用者返回成功;现在我们将生成一个稍微好一点的消息并返回一个错误)。
作为更好的错误消息的一部分：
- 不再有段错误
- 指向 yyy 中的"
xxx"的错误标记指针 - 或者：
yyy中的未知标记类型'xxx'