Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.39.3 → 2.42.0 no changes
-
2.39.2
02/06/23
- 2.39.1 no changes
-
2.39.0
12/12/22
- 2.38.1 → 2.38.5 no changes
-
2.38.0
10/02/22
- 2.35.1 → 2.37.7 no changes
-
2.35.0
01/24/22
- 2.30.2 → 2.34.8 no changes
-
2.30.1
02/08/21
概述
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] [--[no-]dangling] [--[no-]progress] [--connectivity-only] [--[no-]name-objects] [<object>…]
选项
- <对象>
-
一个要作为不可及性追踪的头的对象。
如果没有给出对象,git fsck 默认使用索引文件、
refs
命名空间中的所有 SHA-1 引用,以及所有引用日志(除非—no-reflogs被给出)作为头。 - --unreachable
-
打印出存在但不能从任何参考节点到达的对象。
- --[no-]dangling
-
打印存在但从未 'directly ' 使用的对象(默认)。
--no-dangling
可以用来从输出中省略这一信息。 - --root
-
报告根节点。
- --tags
-
报告标签。
- --cache
-
考虑将索引中记录的任何对象也作为不可达性追踪的头节点。
- --no-reflogs
-
不认为那些只被引用日志中的条目引用的提交是可以达到的。 这个选项只是为了搜索那些曾经在引用中,但现在不在了,但仍在那个相应引用日志中的提交。
- --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
-
只检查可达对象的连接性,确保可达标签、提交或树所引用的任何对象都存在。这样可以完全避免读取 blobs,从而加快操作速度(尽管它仍然会检查被引用的 blobs 是否存在)。这将检测提交和树的损坏,但不做任何语义检查(例如,格式错误)。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/
。 - --[no-]progress
-
除非指定 --no-progress 或 --verbose,否则当标准错误流连接到终端时,默认情况下会报告进度状态。--progress 即使标准错误流没有指向终端,也会强制显示进度状态。
配置
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
讨论
git-fsck 测试 SHA-1和一般对象的正确性,并对结果的可及性和其他一切进行全面跟踪。它打印出它发现的任何损坏(缺失或坏的对象),如果你使用 --unreachable
标志,它也会打印出存在但从任何指定的头部节点(或默认集,如上所述)无法到达的对象。
任何损坏的对象,你将不得不在备份或其他档案中找到(也就是说,你可以直接删除它们,并与其他网站做一个 rsync,希望别人拥有你损坏的对象)。
如果 core.commitGraph 为真,提交的图形文件也将用 git commit-graph verify 来检查。见 git-commit-graph[1]。
提取的诊断方法
- 无法到达 <类型> <对象> 的问题
-
The <type> object <object>, isn’t actually referred to directly or indirectly in any of the trees or commits seen. This can mean that there’s another root node that you’re not specifying or that the tree is corrupt. If you haven’t missed a root node then you might as well delete unreachable nodes since they can’t be used.
- 缺少 <类型> <对象>
-
<类型> 对象 <object>,被提及但不存在于数据库中。
- 悬空的 <类型> <对象>
-
<类型> 对象 <object>,存在于数据库中,但从未 directly 使用。一个悬空的提交可能是一个根节点。
- 哈希值不匹配 <对象>
-
数据库中有一个对象的哈希值与对象数据库的值不一致。 这表明一个严重的数据完整性问题。
FSCK 信息
下面列出了 git fsck
检测的错误类型和每个错误的含义,以及它们的默认严重程度。 除了那些被标记为 "(FATAL)" 的错误,其他错误的严重程度可以通过设置相应的 fsck.<msg-id>
配置变量来调整。
Warning
|
Missing See original version for this content. |
GIT
属于 git[1] 文档