git-commit: document log message formatting convention
[gitweb.git] / Documentation / git-fsck-objects.txt
index 37e8055d2141a6893991201c628bc07549c04b27..d0af99d3512d3794f9907612cef1d30616120064 100644 (file)
@@ -8,7 +8,9 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
 
 SYNOPSIS
 --------
-'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache] [--standalone | --full] [--strict] [<object>*]
+[verse]
+'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
+                [--full] [--strict] [<object>*]
 
 DESCRIPTION
 -----------
@@ -36,21 +38,14 @@ 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.
 
---standalone::
-       Limit checks to the contents of GIT_OBJECT_DIRECTORY
-       ($GIT_DIR/objects), making sure that it is consistent and
-       complete without referring to objects found in alternate
-       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
-       nor packed git archives found in $GIT_DIR/objects/pack;
-       cannot be used with --full.
-
 --full::
        Check not just objects in GIT_OBJECT_DIRECTORY
        ($GIT_DIR/objects), but also the ones found in alternate
-       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
+       object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
+       or $GIT_DIR/objects/info/alternates,
        and in packed git archives found in $GIT_DIR/objects/pack
        and corresponding pack subdirectories in alternate
-       object pools; cannot be used with --standalone.
+       object pools.
 
 --strict::
        Enable more strict checking, namely to catch a file mode
@@ -68,7 +63,7 @@ that aren't readable from any of the specified head nodes.
 
 So for example
 
-       git-fsck-objects --unreachable $(cat .git/HEAD .git/refs/heads/*)
+       git-fsck-objects --unreachable HEAD $(cat .git/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
@@ -76,7 +71,7 @@ sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
 do have a valid tree.
 
 Any corrupt objects you will have to find in backups or other archives
-(ie 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