Merge branch 'jk/refs-double-abort'
[gitweb.git] / Documentation / git-fsck.txt
index 84ee92e15844588425111c1230b37ac3f0f03038..e0eae642c10f75cff57c0a9d07420e3218235423 100644 (file)
@@ -11,7 +11,8 @@ SYNOPSIS
 [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
 -----------
@@ -61,9 +62,17 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs
        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
@@ -82,6 +91,12 @@ index file, all SHA-1 references in `refs` namespace, and all reflogs
        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
@@ -95,7 +110,7 @@ DISCUSSION
 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).
 
@@ -103,6 +118,9 @@ Any corrupt objects you will have to find in backups or other archives
 (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
 ---------------------
 
@@ -130,9 +148,9 @@ dangling <type> <object>::
        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