git - git fsck 分段错误目录

Question

我在 Rubymine 中使用 git。在另一个提交之后，我打开了 git push 窗口并看到object file .git/object/55/4d...e6 is emptyunable to read ....了提交名称而不是提交名称。

跑步git fsck -full给了我这个： Segmentation faultrectories: 33% (85/256)

有什么我可以在这里做的吗？

Answer 1

Git 2.25（2020 年第一季度）应该解决一个可能的git fsck段错误原因。
随着时间的推移，该命令围绕对象解析和低级对象访问积累了繁琐的代码和逻辑，目前正在修复中。

See commit b2f2039 , commit c5b4269 , commit 103fb6d , commit f648ee7 , commit cc57900 , commit 7854399 , commit b8b00f1 , commit 6da40b2 , commit 3837025 , commit f597937 , commit 5afc4b1 , commit 82ef89b , commit 7339029 , commit d40bbc1 , commit a59cfb3 , commit 23a173a , commit 2175a0c，提交 ec65231，提交 1de6007，提交 78d5014，提交 12736d2，提交 c78fe00（2019 年 10 月 18 日）和提交 228c78f（2019 年 10 月 25 日），由Jeff King ( peff)提交。
^{（由Junio C Hamano 合并gitster——在提交 0e07c1c中，2019 年 12 月 1 日）}

parse_commit_buffer(): 将lookup_commit()失败视为解析错误

^{签字人：杰夫·金}

在解析提交的父节点时，如果我们能够解析一个实际的 oid 但lookup_commit()失败了（因为我们之前在此过程中将其视为不同的对象类型），我们会默默地忽略父节点，并且不会向呼叫者。

调用者无法知道发生了这种情况，因为即使是空的父列表也是有效的解析结果。结果，有可能欺骗我们的“ rev-list”连接检查以接受一组损坏的对象。

这导致：

parse_tag_buffer(): 将NULL标记指针视为解析错误

^{签字人：杰夫·金}

解析标签NULL时，如果类型不匹配（例如，标签声称指向对象X作为提交，但我们之前X在同一进程中将其视为 blob），我们可能会以“已标记”字段结束，但我们确实这样做了否则不向调用者指示解析失败。

这类似于之前提交中讨论的情况，其中提交可能以NULL树字段结束：虽然对于想要忽略损坏对象的调用者来说稍微方便，但这意味着普通调用者必须显式处理这种情况（而不是而不仅仅是依靠解析的返回码）。
大多数人不会，从而导致像c77722b3ea中的段错误修复（“使用get_tagged_oid()”，2019-09-05，Git v2.24.0-rc0 -合并在批次 #4中列出）。

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

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

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

• 没有更多的段错误
• xxxyyy 中指向“”的错误标记指针
• 或：未知标签类型“ xxx”在yyy