Documentation formatting and cleanup

diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 4cc26fb744e892115d8bfa099e48acc102a8689b..ef4ceb3dfdabebbd99d8f238326950701e568e51 100644 (file)
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
 SYNOPSIS
 --------
 [verse]
-'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
         [--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.
 
@@ -79,15 +79,15 @@ 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 $(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
-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 +151,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