简体中文 ▾ 主题 ▾ 最新版本 ▾ git-fsck 最后更新于 2.52.0

名称

git-fsck - 验证数据库中对象的连接性和有效性

概要

git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
	 [--[no-]full] [--strict] [--verbose] [--lost-found]
	 [--[no-]dangling] [--[no-]progress] [--connectivity-only]
	 [--[no-]name-objects] [--[no-]references] [<object>…​]

描述

验证数据库中对象的连接性和有效性。

选项

<object>

一个用于作为不可达跟踪的起点的对象。

如果没有给出对象，git fsck 默认使用索引文件、refs 命名空间下的所有 SHA-1 引用以及所有 reflog（除非给出了 --no-reflogs）作为起点。

--unreachable

打印存在但无法从任何引用节点到达的对象。

--dangling
--no-dangling

打印存在但从未被 *直接* 使用过的对象（默认）。--no-dangling 可用于从输出中省略此信息。

--root

报告根节点。

--tags

报告标签。

--cache

将索引中记录的任何对象也视为不可达跟踪的起点。

--no-reflogs

不要将仅由 reflog 条目引用的提交视为可达。此选项仅用于查找曾经在 ref 中但现在不再存在，但仍存在于相应 reflog 中的提交。

--full

不仅检查 GIT_OBJECT_DIRECTORY ($GIT_DIR/objects) 中的对象，还检查 GIT_ALTERNATE_OBJECT_DIRECTORIES 或 $GIT_DIR/objects/info/alternates 中列出的备用对象池中找到的对象，以及 $GIT_DIR/objects/pack 和备用对象池中相应 pack 子目录中找到的已打包 Git 存档。这现在是默认行为；您可以使用 --no-full 关闭它。

--connectivity-only

仅检查可达对象的连接性，确保任何被可达标签、提交或树引用的对象都存在。通过避免完全读取 blob 来加快操作速度（尽管仍然会检查引用的 blob 是否存在）。这将检测提交和树中的损坏，但不会进行任何语义检查（例如，格式错误）。blob 对象中的损坏将根本不会被检测到。

不可达的标签、提交和树也将被访问，以找到悬空历史段的末端。如果您不关心此输出并希望进一步加快速度，请使用 --no-dangling。

--strict

启用更严格的检查，即捕获用 g+w 位集记录的文件模式，该文件模式是由旧版本 Git 创建的。现有存储库，包括 Linux 内核、Git 本身和稀疏存储库，都包含会触发此检查的旧对象，但建议使用此标志检查新项目。

--verbose

啰嗦。

--lost-found

将悬空对象写入 .git/lost-found/commit/ 或 .git/lost-found/other/，具体取决于类型。如果对象是 blob，则其内容将写入文件，而不是其对象名称。

--name-objects

在显示可达对象的名称时，除了 SHA-1 之外，还会显示一个描述对象 *如何* 可达的名称，与 git-rev-parse[1] 兼容，例如 HEAD@{1234567890}~25^2:src/。

--progress
--no-progress

默认情况下，当标准错误流连接到终端时，会报告进度状态，除非指定了 --no-progress 或 --verbose。--progress 会强制报告进度状态，即使标准错误流未定向到终端。

--references
--no-references

控制是否通过 git refs verify 检查引用数据库的一致性。有关详细信息，请参阅 git-refs[1]。默认行为是检查引用数据库。

配置

本节中以下所有内容均从 git-config[1] 文档中选择性地包含。内容与彼处相同：

fsck.<msg-id>

在 fsck 期间，git 可能会发现旧数据存在问题，这些问题不会被当前版本的 git 生成，并且在设置 transfer.fsckObjects 时不会通过网络传输。此功能旨在支持处理包含此类数据的旧存储库。

设置 fsck.<msg-id> 将被 git-fsck[1] 读取，但要接受此类数据的推送，请改而设置 receive.fsck.<msg-id>，或者要克隆或获取它，请设置 fetch.fsck.<msg-id>。

其余文档为了简洁起见，讨论的是 fsck.*，但相同的规则也适用于相应的 receive.fsck.* 和 fetch.fsck.* 变量。

与 color.ui 和 core.editor 等变量不同，如果 receive.fsck.<msg-id> 和 fetch.fsck.<msg-id> 变量未设置，它们不会回退到 fsck.<msg-id> 配置。要统一配置在不同情况下相同的 fsck 设置，必须将这三个都设置为相同的值。

当设置 fsck.<msg-id> 时，可以通过配置 fsck.<msg-id> 设置将错误切换为警告，反之亦然，其中 <msg-id> 是 fsck 消息 ID，值为 error、warn 或 ignore 之一。为了方便起见，fsck 会在错误/警告前加上消息 ID，例如“missingEmail: invalid author/committer line - missing email”表示设置 fsck.missingEmail = ignore 将隐藏此问题。

总的来说，最好使用 fsck.skipList 来枚举存在问题的现有对象，而不是列出这些有问题对象共享的需要被忽略的故障类型，因为后者会允许同一故障的新实例在未被注意的情况下出现。

设置一个未知的 fsck.<msg-id> 值将导致 fsck 退出，但对 receive.fsck.<msg-id> 和 fetch.fsck.<msg-id> 执行相同操作只会导致 git 给出警告。

有关受支持的 <msg-id> 值，请参阅 git-fsck[1] 的“Fsck Messages”部分。

fsck.skipList

一个对象名称列表（即每行一个未缩写的 SHA-1）的路径，这些对象已知存在非致命性损坏，应被忽略。在 Git 2.20 及更高版本中，会忽略注释（#）、空行以及任何前导和尾随空格。在旧版本中，除了每行一个 SHA-1 之外的任何内容都会导致错误。

当一个已建立的项目应该被接受，即使早期提交包含可以安全忽略的错误（例如无效的提交者电子邮件地址）时，此功能非常有用。注意：无法通过此设置跳过损坏的对象。

与 fsck.<msg-id> 类似，此变量具有相应的 receive.fsck.skipList 和 fetch.fsck.skipList 变体。

与 color.ui 和 core.editor 等变量不同，receive.fsck.skipList 和 fetch.fsck.skipList 变量在未设置时不会回退到 fsck.skipList 配置。要统一配置在不同情况下相同的 fsck 设置，必须将这三个都设置为相同的值。

旧版本的 Git（2.20 之前）曾记录对象名称列表应排序。这从未是必需的；对象名称可以按任何顺序出现，但在读取列表时，我们会跟踪列表是否已排序，以便内部二进制搜索实现可以节省已排序列表的一些工作。除非您有一个巨大的列表，否则没有理由去预先对列表进行排序。在 Git 版本 2.20 之后，改用了哈希实现，因此现在没有理由预先对列表进行排序。

讨论

git-fsck 测试 SHA-1 和一般对象的健全性，并且完全跟踪由此产生的可达性和其他一切。它会打印出它发现的所有损坏（丢失或错误的［对象］），并且如果您使用 --unreachable 标志，它还会打印出存在但无法从任何指定头部节点（或如上所述的默认集合）到达的对象。

任何损坏的对象，您都必须从备份或其他存档中查找（即，您可以删除它们并与另一个站点进行 rsync，希望其他人拥有您损坏的对象）。

如果 core.commitGraph 为 true，则还会使用 git commit-graph verify 检查 commit-graph 文件。请参阅 git-commit-graph[1]。

提取的诊断信息

unreachable <type> <object>

该 <type> 对象 <object>，实际上并没有在任何看到的树或提交中被直接或间接引用。这可能意味着有一个您未指定的其他根节点，或者树已损坏。如果您没有遗漏根节点，那么您可以删除不可达节点，因为它们无法使用。

missing <type> <object>

该 <type> 对象 <object>，被引用但不存在于数据库中。

dangling <type> <object>

该 <type> 对象 <object>，存在于数据库中但从未被 *直接* 使用。悬空提交可能是一个根节点。

hash mismatch <object>

数据库中有一个对象的哈希值与对象数据库的值不匹配。这表明存在严重的数据完整性问题。

FSCK MESSAGES

以下列出了 git fsck 检测到的错误类型及其含义和默认严重性。除标记为“(FATAL)”的错误外，错误的严重性都可以通过设置相应的 fsck.<msg-id> 配置变量来调整。

badDate

(ERROR) 作者/提交者行中的日期格式无效。

badDateOverflow

(ERROR) 作者/提交者行中的日期值无效。

badEmail

(ERROR) 作者/提交者行中的电子邮件格式无效。

badFilemode

(INFO) 树中包含无效的文件模式条目。

badGpgsig

(ERROR) 标签包含无效（截断）的签名（例如，gpgsig）头。

badHeaderContinuation

(ERROR) 继续头（例如，用于 gpgsig）意外被截断。

badName

(ERROR) 作者/提交者姓名为空。

badObjectSha1

(ERROR) 对象具有无效的 sha1。

badPackedRefEntry

(ERROR) "packed-refs" 文件包含无效条目。

badPackedRefHeader

(ERROR) "packed-refs" 文件包含无效头。

badParentSha1

(ERROR) 提交对象具有无效的父 sha1。

badRefContent

(ERROR) ref 具有无效内容。

badRefFiletype

(ERROR) ref 具有无效的文件类型。

badRefName

(ERROR) ref 格式无效。

badReferentName

(ERROR) 符号引用的目标名称无效。

badReftableTableName

(WARN) reftable 表名称无效。

badTagName

(INFO) 标签格式无效。

badTimezone

(ERROR) 在作者/提交者行中发现无效时区。

badTree

(ERROR) 树无法解析。

badTreeSha1

(ERROR) 树格式无效。

badType

(ERROR) 在对象类型中发现无效的对象类型。

duplicateEntries

(ERROR) 树包含重复的文件条目。

emptyName

(WARN) 路径包含空名称。

emptyPackedRefsFile

(INFO) "packed-refs" 文件为空。如果您看到此错误，请报告给 git@vger.kernel.org 邮件列表。由于只有非常早期的 Git 版本会创建如此空的 "packed_refs" 文件，我们将来可能会收紧此规则。

extraHeaderEntry

(IGNORE) 在 tagger 之后找到额外的头。

fullPathname

(WARN) 路径包含以“/”开头的完整路径。

gitattributesBlob

(ERROR) 在 .gitattributes 处找到非 blob 对象。

gitattributesLarge

(ERROR) .gitattributes blob 太大。

gitattributesLineLength

(ERROR) .gitattributes blob 包含过长的行。

gitattributesMissing

(ERROR) 无法读取 .gitattributes blob。

gitattributesSymlink

(INFO) .gitattributes 是一个符号链接。

gitignoreSymlink

(INFO) .gitignore 是一个符号链接。

gitmodulesBlob

(ERROR) 在 .gitmodules 处找到非 blob 对象。

gitmodulesLarge

(ERROR) .gitmodules 文件太大，无法解析。

gitmodulesMissing

(ERROR) 无法读取 .gitmodules blob。

gitmodulesName

(ERROR) 子模块名称无效。

gitmodulesParse

(INFO) 无法解析 .gitmodules blob。

gitmodulesPath

(ERROR) .gitmodules 路径无效。

gitmodulesSymlink

(ERROR) .gitmodules 是一个符号链接。

gitmodulesUpdate

(ERROR) 发现无效的子模块更新设置。

gitmodulesUrl

(ERROR) 发现无效的子模块 URL。

hasDot

(WARN) 树包含名为 . 的条目。

hasDotdot

(WARN) 树包含名为 .. 的条目。

hasDotgit

(WARN) 树包含名为 .git 的条目。

largePathname

(WARN) 树包含具有非常长路径名的条目。如果 fsck.largePathname 的值为冒号，则该值用作允许的最大长度（例如，“warn:10”将抱怨任何长度为 11 个或更多字节的路径组件）。默认值为 4096。

mailmapSymlink

(INFO) .mailmap 是一个符号链接。

missingAuthor

(ERROR) 作者丢失。

missingCommitter

(ERROR) 提交者丢失。

missingEmail

(ERROR) 作者/提交者行中缺少电子邮件。

missingNameBeforeEmail

(ERROR) 作者/提交者行中电子邮件前的名称丢失。

missingObject

(ERROR) 标签对象中缺少 object 行。

missingSpaceBeforeDate

(ERROR) 作者/提交者行中日期前的空格丢失。

missingSpaceBeforeEmail

(ERROR) 作者/提交者行中电子邮件前的空格丢失。

missingTag

(ERROR) 标签对象中 type 行后意外结束。

missingTagEntry

(ERROR) 标签对象中缺少 tag 行。

missingTaggerEntry

(INFO) 标签对象中缺少 tagger 行。

missingTree

(ERROR) 提交对象中缺少 tree 行。

missingType

(ERROR) 标签对象 type 行中的类型值无效。

missingTypeEntry

(ERROR) 标签对象中缺少 type 行。

multipleAuthors

(ERROR) 提交中发现多个作者行。

nulInCommit

(WARN) 在提交对象正文中发现 NUL 字节。

nulInHeader

(FATAL) 对象头中存在 NUL 字节。

nullSha1

(WARN) 树包含指向 null sha1 的条目。

packedRefEntryNotTerminated

(ERROR) "packed-refs" 文件包含一个未以换行符结束的条目。

packedRefUnsorted

(ERROR) "packed-refs" 文件未排序。

refMissingNewline

(INFO) 一个松散的 ref 不以换行符 (LF) 结尾。由于有效的 Git 实现从不创建如此松散的 ref 文件，因此将来它可能会成为一个错误。如果您看到此错误，请报告给 git@vger.kernel.org 邮件列表，因为我们需要知道哪些工具创建了这样的文件。

symlinkRef

(INFO) 符号链接用作符号引用。如果您看到此错误，请报告给 git@vger.kernel.org 邮件列表，因为我们正在评估放弃创建符号链接作为符号引用的可行性。

symrefTargetIsNotARef

(INFO) 符号引用的目标既不是根引用，也不是以“refs/”开头的引用。尽管我们允许使用 git symbolic-ref 创建指向 ref 外部的引用的符号引用，但我们将来可能会收紧此规则。如果您看到此错误，请报告给 git@vger.kernel.org 邮件列表，因为我们需要知道哪些工具创建了这样的文件。

trailingRefContent

(INFO) 松散的 ref 包含尾随内容。由于有效的 Git 实现从不创建如此松散的 ref 文件，因此将来它可能会成为一个错误。如果您看到此错误，请报告给 git@vger.kernel.org 邮件列表，因为我们需要知道哪些工具创建了这样的文件。

treeNotSorted

(ERROR) 树未正确排序。

unknownType

(ERROR) 发现未知对象类型。

unterminatedHeader

(FATAL) 对象头中缺少行尾。

zeroPaddedDate

(ERROR) 在作者/提交者行中发现零填充日期。

zeroPaddedFilemode

(WARN) 在树中发现零填充的文件模式。

环境变量

GIT_OBJECT_DIRECTORY

用于指定对象数据库根目录（通常是 $GIT_DIR/objects）

GIT_INDEX_FILE

用于指定索引文件的索引

GIT_ALTERNATE_OBJECT_DIRECTORIES

用于指定额外的对象数据库根目录（通常未设置）

GIT

Git[1] 套件的一部分