Documentation: reset: describe new "--keep" option

diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 4cc26fb744e892115d8bfa099e48acc102a8689b..3ad48a633663ec22af16b4737c42fd7e7664e4d2 100644 (file)
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -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] [--no-reflogs]
-        [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+        [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
 
 DESCRIPTION
 -----------
@@ -21,7 +21,7 @@ OPTIONS
 <object>::
        An object to treat as the head of an unreachability trace.
 +
-If no objects are given, git-fsck defaults to using the
+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.
 
@@ -52,7 +52,8 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
        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.
+       object pools.  This is now default; you can turn it off
+       with --no-full.
 
 --strict::
        Enable more strict checking, namely to catch a file mode
@@ -79,15 +80,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
@@ -151,4 +153,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
 
 GIT
 ---
-Part of the linkgit:git[7] suite
+Part of the linkgit:git[1] suite