diff: add option to show context between close hunks
[gitweb.git] / Documentation / git-fsck.txt
index 058009d2fab4c73edcbfefe7b48c5f9348459da3..287c4fc5e07ea753c2a3d93bf6480f41aac8c9af 100644 (file)
@@ -9,8 +9,8 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
 SYNOPSIS
 --------
 [verse]
-'git-fsck' [--tags] [--root] [--unreachable] [--cache]
-                [--full] [--strict] [<object>*]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+        [--full] [--strict] [--verbose] [--lost-found] [<object>*]
 
 DESCRIPTION
 -----------
@@ -21,8 +21,9 @@ OPTIONS
 <object>::
        An object to treat as the head of an unreachability trace.
 +
-If no objects are given, git-fsck defaults to using the
-index file and all SHA1 references in .git/refs/* as heads.
+If no objects are given, 'git-fsck' defaults to using the
+index file, all SHA1 references in .git/refs/*, and all reflogs (unless
+--no-reflogs is given) as heads.
 
 --unreachable::
        Print out objects that exist but that aren't readable from any
@@ -38,6 +39,12 @@ index file and all SHA1 references in .git/refs/* as heads.
        Consider any object recorded in the index also as a head node for
        an unreachability trace.
 
+--no-reflogs::
+       Do not consider commits that are referenced only by an
+       entry in a reflog to be reachable.  This option is meant
+       only to search for commits that used to be in a ref, but
+       now aren't, but are still in that corresponding reflog.
+
 --full::
        Check not just objects in GIT_OBJECT_DIRECTORY
        ($GIT_DIR/objects), but also the ones found in alternate
@@ -55,6 +62,15 @@ index file and all SHA1 references in .git/refs/* as heads.
        objects that triggers this check, but it is recommended
        to check new projects with this flag.
 
+--verbose::
+       Be chatty.
+
+--lost-found::
+       Write dangling objects into .git/lost-found/commit/ or
+       .git/lost-found/other/, depending on type.  If the object is
+       a blob, the contents are written into the file, rather than
+       its object name.
+
 It tests SHA1 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
@@ -63,15 +79,16 @@ that aren't readable from any of the specified head nodes.
 
 So for example
 
-       git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
+       git fsck --unreachable HEAD \
+               $(git for-each-ref --format="%(objectname)" refs/heads)
 
 will do quite a _lot_ of verification on the tree. There are a few
 extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if "git-fsck" is happy, you
+sorted properly etc), but on the whole if 'git-fsck' is happy, you
 do have a valid tree.
 
 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
+(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).
 
 Of course, "valid tree" doesn't mean that it wasn't generated by some
@@ -135,5 +152,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
 
 GIT
 ---
-Part of the gitlink:git[7] suite
-
+Part of the linkgit:git[1] suite