[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--[no-]full] [--strict] [--verbose] [--lost-found]
- [--[no-]dangling] [--[no-]progress] [--connectivity-only] [<object>*]
+ [--[no-]dangling] [--[no-]progress] [--connectivity-only]
+ [--[no-]name-objects] [<object>*]
DESCRIPTION
-----------
with --no-full.
--connectivity-only::
- Check only the connectivity of tags, commits and tree objects. By
- avoiding to unpack blobs, this speeds up the operation, at the
- expense of missing corrupt objects or other problematic issues.
+ Check only the connectivity of reachable objects, making sure
+ that any objects referenced by a reachable tag, commit, or tree
+ is present. This speeds up the operation by avoiding reading
+ blobs entirely (though it does still check that referenced blobs
+ exist). This will detect corruption in commits and trees, but
+ not do any semantic checks (e.g., for format errors). Corruption
+ in blob objects will not be detected at all.
++
+Unreachable tags, commits, and trees will also be accessed to find the
+tips of dangling segments of history. Use `--no-dangling` if you don't
+care about this output and want to speed it up further.
--strict::
Enable more strict checking, namely to catch a file mode
a blob, the contents are written into the file, rather than
its object name.
+--name-objects::
+ When displaying names of reachable objects, in addition to the
+ SHA-1 also display a name that describes *how* they are reachable,
+ compatible with linkgit:git-rev-parse[1], e.g.
+ `HEAD@{1234567890}~25^2:src/`.
+
--[no-]progress::
Progress status is reported on the standard error stream by
default when it is attached to a terminal, unless
git-fsck tests SHA-1 and general object sanity, and it does full tracking
of the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
-'--unreachable' flag it will also print out objects that exist but that
+`--unreachable` flag it will also print out objects that exist but that
aren't reachable from any of the specified head nodes (or the default
set, as mentioned above).
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
+If core.commitGraph is true, the commit-graph file will also be inspected
+using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
+
Extracted Diagnostics
---------------------
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
-sha1 mismatch <object>::
- The database has an object who's sha1 doesn't match the
- database value.
+hash mismatch <object>::
+ The database has an object whose hash doesn't match the
+ object database value.
This indicates a serious data integrity problem.
Environment Variables