From fce7c7e1549d1a2a2b0faf5952378236eed4d468 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junio@hera.kernel.org>
Date: Wed, 2 Jul 2008 03:06:38 +0000
Subject: [PATCH] Autogenerated HTML docs for v1.5.6.1-156-ge903b

---
 RelNotes-1.5.6.2.txt                  |  31 +++++
 RelNotes-1.6.0.txt                    |  29 ++++-
 config.txt                            |  22 +++-
 diff-options.txt                      |   2 +-
 everyday.html                         |   2 +-
 git-add.html                          |   6 +-
 git-add.txt                           |   4 +-
 git-am.html                           |   6 +-
 git-am.txt                            |   4 +-
 git-annotate.html                     |   4 +-
 git-annotate.txt                      |   2 +-
 git-apply.html                        |  30 +++--
 git-apply.txt                         |  21 ++--
 git-archimport.html                   |  10 +-
 git-archimport.txt                    |   8 +-
 git-archive.html                      |  10 +-
 git-archive.txt                       |   8 +-
 git-bisect.html                       |  10 +-
 git-bisect.txt                        |   8 +-
 git-blame.html                        |   8 +-
 git-blame.txt                         |   6 +-
 git-branch.html                       |  18 +--
 git-branch.txt                        |  16 +--
 git-bundle.html                       |  43 ++++---
 git-bundle.txt                        |  41 ++++---
 git-cat-file.html                     |   6 +-
 git-cat-file.txt                      |   4 +-
 git-check-attr.html                   |   4 +-
 git-check-attr.txt                    |   2 +-
 git-check-ref-format.html             |   6 +-
 git-check-ref-format.txt              |   4 +-
 git-checkout-index.html               |  24 ++--
 git-checkout-index.txt                |  22 ++--
 git-checkout.html                     |  14 +--
 git-checkout.txt                      |  12 +-
 git-cherry-pick.html                  |   6 +-
 git-cherry-pick.txt                   |   4 +-
 git-cherry.html                       |  12 +-
 git-cherry.txt                        |  10 +-
 git-citool.html                       |   6 +-
 git-citool.txt                        |   4 +-
 git-clean.html                        |   8 +-
 git-clean.txt                         |   6 +-
 git-clone.html                        |  16 +--
 git-clone.txt                         |  14 +--
 git-commit-tree.html                  |   6 +-
 git-commit-tree.txt                   |   4 +-
 git-commit.html                       |  30 ++---
 git-commit.txt                        |  28 ++---
 git-config.html                       |  61 ++++++----
 git-config.txt                        |  38 +++----
 git-count-objects.html                |   6 +-
 git-count-objects.txt                 |   4 +-
 git-cvsexportcommit.html              |  15 +--
 git-cvsexportcommit.txt               |  13 ++-
 git-cvsimport.html                    |  22 ++--
 git-cvsimport.txt                     |  20 ++--
 git-cvsserver.html                    |  46 ++++----
 git-cvsserver.txt                     |  45 ++++----
 git-daemon.html                       |  26 ++---
 git-daemon.txt                        |  34 +++---
 git-describe.html                     |  16 +--
 git-describe.txt                      |  14 +--
 git-diff-files.html                   |   8 +-
 git-diff-files.txt                    |   4 +-
 git-diff-index.html                   |  38 +++----
 git-diff-index.txt                    |  34 +++---
 git-diff-tree.html                    |  22 ++--
 git-diff-tree.txt                     |  18 +--
 git-diff.html                         |  22 ++--
 git-diff.txt                          |  18 +--
 git-fast-export.html                  |  12 +-
 git-fast-export.txt                   |  10 +-
 git-fast-import.html                  |  26 ++---
 git-fast-import.txt                   |  24 ++--
 git-fetch-pack.html                   |  20 ++--
 git-fetch-pack.txt                    |  18 +--
 git-fetch.html                        |   6 +-
 git-fetch.txt                         |   4 +-
 git-filter-branch.html                |  16 +--
 git-filter-branch.txt                 |  14 +--
 git-fmt-merge-msg.html                |   6 +-
 git-fmt-merge-msg.txt                 |   4 +-
 git-for-each-ref.html                 |  10 +-
 git-for-each-ref.txt                  |   8 +-
 git-format-patch.html                 |  10 +-
 git-format-patch.txt                  |   6 +-
 git-fsck-objects.html                 |   4 +-
 git-fsck-objects.txt                  |   2 +-
 git-fsck.html                         |  12 +-
 git-fsck.txt                          |  10 +-
 git-gc.html                           |  18 +--
 git-gc.txt                            |  16 +--
 git-get-tar-commit-id.html            |  10 +-
 git-get-tar-commit-id.txt             |   8 +-
 git-grep.html                         |   6 +-
 git-grep.txt                          |   4 +-
 git-gui.html                          |  26 ++---
 git-gui.txt                           |  24 ++--
 git-hash-object.html                  |   6 +-
 git-hash-object.txt                   |   4 +-
 git-help.html                         |   8 +-
 git-help.txt                          |   6 +-
 git-http-fetch.html                   |   6 +-
 git-http-fetch.txt                    |   4 +-
 git-http-push.html                    |   4 +-
 git-http-push.txt                     |   2 +-
 git-imap-send.html                    |   8 +-
 git-imap-send.txt                     |   6 +-
 git-index-pack.html                   |  14 +--
 git-index-pack.txt                    |  12 +-
 git-init-db.html                      |   4 +-
 git-init-db.txt                       |   2 +-
 git-init.html                         |   8 +-
 git-init.txt                          |   6 +-
 git-instaweb.html                     |  10 +-
 git-instaweb.txt                      |   8 +-
 git-log.html                          |  10 +-
 git-log.txt                           |   6 +-
 git-lost-found.html                   |   4 +-
 git-lost-found.txt                    |   2 +-
 git-ls-files.html                     |  12 +-
 git-ls-files.txt                      |  10 +-
 git-ls-remote.html                    |   6 +-
 git-ls-remote.txt                     |   4 +-
 git-ls-tree.html                      |   4 +-
 git-ls-tree.txt                       |   2 +-
 git-mailinfo.html                     |  10 +-
 git-mailinfo.txt                      |   8 +-
 git-mailsplit.html                    |   4 +-
 git-mailsplit.txt                     |   2 +-
 git-merge-base.html                   |  12 +-
 git-merge-base.txt                    |  10 +-
 git-merge-file.html                   |  16 +--
 git-merge-file.txt                    |  14 +--
 git-merge-index.html                  |  22 ++--
 git-merge-index.txt                   |  20 ++--
 git-merge-one-file.html               |   6 +-
 git-merge-one-file.txt                |   4 +-
 git-merge-tree.html                   |   4 +-
 git-merge-tree.txt                    |   2 +-
 git-merge.html                        |  25 ++--
 git-merge.txt                         |  24 ++--
 git-mergetool.html                    |  20 ++--
 git-mergetool.txt                     |  18 +--
 git-mktag.html                        |   4 +-
 git-mktag.txt                         |   2 +-
 git-mktree.html                       |   4 +-
 git-mktree.txt                        |   2 +-
 git-mv.html                           |   8 +-
 git-mv.txt                            |   6 +-
 git-name-rev.html                     |  10 +-
 git-name-rev.txt                      |   8 +-
 git-pack-objects.html                 |  10 +-
 git-pack-objects.txt                  |  10 +-
 git-pack-redundant.html               |  10 +-
 git-pack-redundant.txt                |  10 +-
 git-pack-refs.html                    |   6 +-
 git-pack-refs.txt                     |   4 +-
 git-parse-remote.html                 |   2 +-
 git-patch-id.html                     |   6 +-
 git-patch-id.txt                      |   4 +-
 git-peek-remote.html                  |   8 +-
 git-peek-remote.txt                   |   6 +-
 git-prune-packed.html                 |   4 +-
 git-prune-packed.txt                  |   2 +-
 git-prune.html                        |  16 +--
 git-prune.txt                         |  14 +--
 git-pull.html                         |   7 +-
 git-pull.txt                          |   5 +-
 git-push.html                         |   6 +-
 git-push.txt                          |   4 +-
 git-quiltimport.html                  |   4 +-
 git-quiltimport.txt                   |   2 +-
 git-read-tree.html                    |  48 ++++----
 git-read-tree.txt                     |  46 ++++----
 git-rebase.html                       |  40 +++----
 git-rebase.txt                        |  38 +++----
 git-receive-pack.html                 |  26 ++---
 git-receive-pack.txt                  |  24 ++--
 git-reflog.html                       |   2 +-
 git-relink.html                       |   4 +-
 git-relink.txt                        |   2 +-
 git-remote.html                       |  14 +--
 git-remote.txt                        |  12 +-
 git-repack.html                       |  17 +--
 git-repack.txt                        |  15 +--
 git-repo-config.html                  |   4 +-
 git-repo-config.txt                   |   2 +-
 git-request-pull.html                 |   4 +-
 git-request-pull.txt                  |   2 +-
 git-rerere.html                       |  16 +--
 git-rerere.txt                        |  14 +--
 git-reset.html                        |   4 +-
 git-reset.txt                         |   2 +-
 git-rev-list.html                     |  18 +--
 git-rev-list.txt                      |  16 +--
 git-rev-parse.html                    |  20 ++--
 git-rev-parse.txt                     |  18 +--
 git-revert.html                       |   4 +-
 git-revert.txt                        |   2 +-
 git-rm.html                           |  12 +-
 git-rm.txt                            |  10 +-
 git-send-email.html                   |  30 ++++-
 git-send-email.txt                    |  18 ++-
 git-send-pack.html                    |  18 +--
 git-send-pack.txt                     |  16 +--
 git-sh-setup.html                     |   2 +-
 git-shell.html                        |   4 +-
 git-shell.txt                         |   2 +-
 git-shortlog.html                     |   8 +-
 git-shortlog.txt                      |   6 +-
 git-show-branch.html                  |  10 +-
 git-show-branch.txt                   |   8 +-
 git-show-index.html                   |   8 +-
 git-show-index.txt                    |   6 +-
 git-show-ref.html                     |  12 +-
 git-show-ref.txt                      |  10 +-
 git-show.html                         |  10 +-
 git-show.txt                          |   8 +-
 git-stash.html                        |  24 ++--
 git-stash.txt                         |  22 ++--
 git-status.html                       |   8 +-
 git-status.txt                        |   6 +-
 git-stripspace.html                   |   4 +-
 git-stripspace.txt                    |   2 +-
 git-submodule.html                    |  16 +--
 git-submodule.txt                     |  14 +--
 git-svn.html                          | 157 +++++++++++++-------------
 git-svn.txt                           | 153 +++++++++++++------------
 git-symbolic-ref.html                 |   6 +-
 git-symbolic-ref.txt                  |   4 +-
 git-tag.html                          |  20 ++--
 git-tag.txt                           |  18 +--
 git-tar-tree.html                     |   8 +-
 git-tar-tree.txt                      |   6 +-
 git-tools.html                        |   2 +-
 git-unpack-file.html                  |   4 +-
 git-unpack-file.txt                   |   2 +-
 git-unpack-objects.html               |   6 +-
 git-unpack-objects.txt                |   4 +-
 git-update-index.html                 |  28 ++---
 git-update-index.txt                  |  26 ++---
 git-update-ref.html                   |  12 +-
 git-update-ref.txt                    |  10 +-
 git-update-server-info.html           |   6 +-
 git-update-server-info.txt            |   4 +-
 git-upload-archive.html               |   6 +-
 git-upload-archive.txt                |   4 +-
 git-upload-pack.html                  |  10 +-
 git-upload-pack.txt                   |   8 +-
 git-var.html                          |   6 +-
 git-var.txt                           |   4 +-
 git-verify-pack.html                  |   8 +-
 git-verify-pack.txt                   |   6 +-
 git-verify-tag.html                   |   6 +-
 git-verify-tag.txt                    |   4 +-
 git-web--browse.html                  |  12 +-
 git-web--browse.txt                   |  10 +-
 git-whatchanged.html                  |  12 +-
 git-whatchanged.txt                   |  10 +-
 git-write-tree.html                   |   4 +-
 git-write-tree.txt                    |   2 +-
 git.html                              |  32 +++---
 git.txt                               |  30 ++---
 gitattributes.html                    |  20 ++--
 gitattributes.txt                     |  18 +--
 gitcli.html                           |  45 +++++++-
 gitcli.txt                            |  38 ++++++-
 gitcore-tutorial.html                 | 129 +++++++++++----------
 gitcore-tutorial.txt                  | 127 +++++++++++----------
 gitcvs-migration.html                 |  26 ++---
 gitcvs-migration.txt                  |  24 ++--
 gitdiffcore.html                      |  36 +++---
 gitdiffcore.txt                       |  34 +++---
 gitglossary.html                      |   2 +-
 githooks.html                         |  12 +-
 githooks.txt                          |  10 +-
 gitignore.html                        |  10 +-
 gitignore.txt                         |   8 +-
 gitk.html                             |   5 +-
 gitk.txt                              |   3 +-
 gitmodules.html                       |   2 +-
 gitrepository-layout.html             |  26 ++---
 gitrepository-layout.txt              |  24 ++--
 gittutorial-2.html                    |  42 ++++---
 gittutorial-2.txt                     |  40 ++++---
 gittutorial.html                      |  68 +++++------
 gittutorial.txt                       |  66 +++++------
 howto-index.html                      |   2 +-
 howto/revert-branch-rebase.html       |   2 +-
 howto/using-merge-subtree.html        |   2 +-
 technical/api-allocation-growing.html |   2 +-
 technical/api-builtin.html            |   2 +-
 technical/api-decorate.html           |   2 +-
 technical/api-diff.html               |   2 +-
 technical/api-directory-listing.html  |   2 +-
 technical/api-gitattributes.html      |   2 +-
 technical/api-grep.html               |   2 +-
 technical/api-hash.html               |   2 +-
 technical/api-history-graph.html      |   2 +-
 technical/api-in-core-index.html      |   2 +-
 technical/api-index.html              |   2 +-
 technical/api-lockfile.html           |   2 +-
 technical/api-object-access.html      |   2 +-
 technical/api-parse-options.html      |   2 +-
 technical/api-path-list.html          |   2 +-
 technical/api-quote.html              |   2 +-
 technical/api-remote.html             |   2 +-
 technical/api-revision-walking.html   |   2 +-
 technical/api-run-command.html        |   2 +-
 technical/api-setup.html              |   2 +-
 technical/api-strbuf.html             |   2 +-
 technical/api-tree-walking.html       |   2 +-
 technical/api-xdiff-interface.html    |   2 +-
 user-manual.html                      |  95 ++++++++--------
 user-manual.txt                       |  85 +++++++-------
 317 files changed, 2318 insertions(+), 2129 deletions(-)
 create mode 100644 RelNotes-1.5.6.2.txt

diff --git a/RelNotes-1.5.6.2.txt b/RelNotes-1.5.6.2.txt
new file mode 100644
index 000000000..02d5910d5
--- /dev/null
+++ b/RelNotes-1.5.6.2.txt
@@ -0,0 +1,31 @@
+GIT v1.5.6.2 Release Notes
+==========================
+
+Futureproof
+-----------
+
+ * "git-shell" accepts requests without a dash between "git" and
+   subcommand name (e.g. "git upload-pack") which the newer client will
+   start to make sometime in the future.
+
+Fixes since v1.5.6.1
+--------------------
+
+* Optimization for a large import via "git-svn" introduced in v1.5.6 had a
+  serious memory and temporary file leak, which made it unusable for
+  moderately large import.
+
+* "git-svn" mangled remote nickname used in the configuration file
+  unnecessarily.
+
+* "git diff --check" did not report the result via its exit status
+  reliably.
+
+* "git show" segfaulted when an annotated tag that points at another
+  annotated tag was given to it.
+
+--
+exec >/var/tmp/1
+echo O=$(git describe maint)
+O=v1.5.6.1-13-g4f3dcc2
+git shortlog --no-merges $O..maint
diff --git a/RelNotes-1.6.0.txt b/RelNotes-1.6.0.txt
index 03e3a59ff..e5c285f9c 100644
--- a/RelNotes-1.6.0.txt
+++ b/RelNotes-1.6.0.txt
@@ -4,9 +4,6 @@ GIT v1.6.0 Release Notes
 User visible changes
 --------------------
 
-[[Note that none of these are not merged to 'master' as of this writing
-but they will be before 1.6.0 happens]]
-
 With the default Makefile settings, most of the programs are now
 installed outside your $PATH, except for "git", "gitk", "git-gui" and
 some server side programs that need to be accessible for technical
@@ -21,6 +18,11 @@ scripts to use "git xyzzy" form, as we will stop installing
 Source changes needed for porting to MinGW environment are now all in the
 main git.git codebase.
 
+By default, packfiles created with this version uses delta-base-offset
+encoding introduced in v1.4.4.  Pack idx files are using version 2 that
+allows larger packs and added robustness thanks to its CRC checking,
+introduced in v1.5.2.
+
 
 Updates since v1.5.6
 --------------------
@@ -77,14 +79,33 @@ Updates since v1.5.6
 
 (usability, bells and whistles)
 
+* git-apply can handle a patch that touches the same path more than once
+  much better than before.
+
+* git-apply can be told not to trust the line counts recorded in the input
+  patch but recount, with the new --recount option.
+
 * git-archive can be told to omit certain paths from its output using
   export-ignore attributes.
 
+* git-clone can clone from a remote whose URL would be rewritten by
+  configuration stored in $HOME/.gitconfig now.
+
+* git-diff --check now checks leftover merge conflict markers.
+
+* When remote side used to have branch 'foo' and git-fetch finds that now
+  it has branch 'foo/bar', it refuses to lose the existing remote tracking
+  branch and its reflog.  The error message has been improved to suggest
+  pruning the remote if the user wants to proceed and get the latest set
+  of branches from the remote, including such 'foo/bar'.
+
 * fast-export learned to export and import marks file; this can be used to
   interface with fast-import incrementally.
 
 * Original SHA-1 value for "update-ref -d" is optional now.
 
+* git-send-mail can talk not just over SSL but over TLS now.
+
 * You can tell "git status -u" to even more aggressively omit checking
   untracked files with --untracked-files=no.
 
@@ -108,6 +129,6 @@ this release, unless otherwise noted.
 
 ---
 exec >/var/tmp/1
-O=v1.5.6.1-104-ga08b868
+O=v1.5.6.1-155-gaa0c1f2
 echo O=$(git describe refs/heads/master)
 git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
diff --git a/config.txt b/config.txt
index 6966384ce..561ff645f 100644
--- a/config.txt
+++ b/config.txt
@@ -945,9 +945,17 @@ pack.indexVersion::
 	legacy pack index used by Git versions prior to 1.5.2, and 2 for
 	the new pack index with capabilities for packs larger than 4 GB
 	as well as proper protection against the repacking of corrupted
-	packs.  Version 2 is selected and this config option ignored
-	whenever the corresponding pack is larger than 2 GB.  Otherwise
-	the default is 1.
+	packs.  Version 2 is the default.  Note that version 2 is enforced
+	and this config option ignored whenever the corresponding pack is
+	larger than 2 GB.
++
+If you have an old git that does not understand the version 2 `{asterisk}.idx` file,
+cloning or fetching over a non native protocol (e.g. "http" and "rsync")
+that will copy both `{asterisk}.pack` file and corresponding `{asterisk}.idx` file from the
+other side may give you a repository that cannot be accessed with your
+older version of git. If the `{asterisk}.pack` file is smaller than 2 GB, however,
+you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
+the `{asterisk}.idx` file.
 
 pack.packSizeLimit::
 	The default maximum size of a pack.  This setting only affects
@@ -1004,8 +1012,12 @@ remotes.<group>::
 	<group>".  See linkgit:git-remote[1].
 
 repack.usedeltabaseoffset::
-	Allow linkgit:git-repack[1] to create packs that uses
-	delta-base offset.  Defaults to false.
+	By default, linkgit:git-repack[1] creates packs that use
+	delta-base offset. If you need to share your repository with
+	git older than version 1.4.4, either directly or via a dumb
+	protocol such as http, then you need to set this option to
+	"false" and repack. Access from old git versions over the
+	native protocol are unaffected by this option.
 
 showbranch.default::
 	The default set of branches for linkgit:git-show-branch[1].
diff --git a/diff-options.txt b/diff-options.txt
index 572154834..cba90fd27 100644
--- a/diff-options.txt
+++ b/diff-options.txt
@@ -241,4 +241,4 @@ endif::git-format-patch[]
 	Do not show any source or destination prefix.
 
 For more detailed explanation on these common options, see also
-linkgit:gitdiffcore[7][diffcore documentation].
+linkgit:gitdiffcore[7].
diff --git a/everyday.html b/everyday.html
index cb4b83de1..702b25de5 100644
--- a/everyday.html
+++ b/everyday.html
@@ -1050,7 +1050,7 @@ upload to public HTTP server hosted by your ISP.
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:35 UTC
+Last updated 02-Jul-2008 03:02:14 UTC
 </div>
 </div>
 </body>
diff --git a/git-add.html b/git-add.html
index 0e7b67808..7ce159e7c 100644
--- a/git-add.html
+++ b/git-add.html
@@ -273,7 +273,7 @@ git-add(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-add</em> [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+<div class="content"><em>git add</em> [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
           [--update | -u] [--refresh] [--ignore-errors] [--]
           &lt;filepattern&gt;&#8230;</div></div>
 </div>
@@ -429,7 +429,7 @@ commit.</p>
 <p>The optional configuration variable <em>core.excludesfile</em> indicates a path to a
 file containing patterns of file names to exclude from git-add, similar to
 $GIT_DIR/info/exclude.  Patterns in the exclude file are used in addition to
-those in info/exclude.  See <a href="gitrepository-layout.html">gitrepository-layout(5)</a>[repository layout].</p>
+those in info/exclude.  See <a href="gitrepository-layout.html">gitrepository-layout(5)</a>.</p>
 </div>
 <h2>EXAMPLES</h2>
 <div class="sectionbody">
@@ -623,7 +623,7 @@ double-quote and control characters will still have problems.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 15-Jun-2008 05:10:05 UTC
+Last updated 02-Jul-2008 03:01:31 UTC
 </div>
 </div>
 </body>
diff --git a/git-add.txt b/git-add.txt
index b8e3fa675..011a74365 100644
--- a/git-add.txt
+++ b/git-add.txt
@@ -8,7 +8,7 @@ git-add - Add file contents to the index
 SYNOPSIS
 --------
 [verse]
-'git-add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
+'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
 	  [--update | -u] [--refresh] [--ignore-errors] [--]
 	  <filepattern>...
 
@@ -107,7 +107,7 @@ Configuration
 The optional configuration variable 'core.excludesfile' indicates a path to a
 file containing patterns of file names to exclude from git-add, similar to
 $GIT_DIR/info/exclude.  Patterns in the exclude file are used in addition to
-those in info/exclude.  See linkgit:gitrepository-layout[5][repository layout].
+those in info/exclude.  See linkgit:gitrepository-layout[5].
 
 
 EXAMPLES
diff --git a/git-am.html b/git-am.html
index eb6c0c57d..830ba2789 100644
--- a/git-am.html
+++ b/git-am.html
@@ -273,11 +273,11 @@ git-am(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-am</em> [--signoff] [--keep] [--utf8 | --no-utf8]
+<div class="content"><em>git am</em> [--signoff] [--keep] [--utf8 | --no-utf8]
          [--3way] [--interactive] [--binary]
          [--whitespace=&lt;option&gt;] [-C&lt;n&gt;] [-p&lt;n&gt;]
          &lt;mbox&gt;|&lt;Maildir&gt;&#8230;
-<em>git-am</em> [--skip | --resolved]</div></div>
+<em>git am</em> [--skip | --resolved]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -524,7 +524,7 @@ names.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:16 UTC
+Last updated 02-Jul-2008 03:01:31 UTC
 </div>
 </div>
 </body>
diff --git a/git-am.txt b/git-am.txt
index 46544a076..1296b9117 100644
--- a/git-am.txt
+++ b/git-am.txt
@@ -9,11 +9,11 @@ git-am - Apply a series of patches from a mailbox
 SYNOPSIS
 --------
 [verse]
-'git-am' [--signoff] [--keep] [--utf8 | --no-utf8]
+'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
          [--3way] [--interactive] [--binary]
          [--whitespace=<option>] [-C<n>] [-p<n>]
          <mbox>|<Maildir>...
-'git-am' [--skip | --resolved]
+'git am' [--skip | --resolved]
 
 DESCRIPTION
 -----------
diff --git a/git-annotate.html b/git-annotate.html
index 4846d3ae1..7467fb487 100644
--- a/git-annotate.html
+++ b/git-annotate.html
@@ -272,7 +272,7 @@ git-annotate(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p>git-annotate [options] file [revision]</p>
+<p><em>git annotate</em> [options] file [revision]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -460,7 +460,7 @@ commit.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:17 UTC
+Last updated 02-Jul-2008 03:01:32 UTC
 </div>
 </div>
 </body>
diff --git a/git-annotate.txt b/git-annotate.txt
index da15379ae..8b6b56a54 100644
--- a/git-annotate.txt
+++ b/git-annotate.txt
@@ -7,7 +7,7 @@ git-annotate - Annotate file lines with commit info
 
 SYNOPSIS
 --------
-git-annotate [options] file [revision]
+'git annotate' [options] file [revision]
 
 DESCRIPTION
 -----------
diff --git a/git-apply.html b/git-apply.html
index 975846595..728322578 100644
--- a/git-apply.html
+++ b/git-apply.html
@@ -273,10 +273,10 @@ git-apply(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-apply</em> [--stat] [--numstat] [--summary] [--check] [--index]
+<div class="content"><em>git apply</em> [--stat] [--numstat] [--summary] [--check] [--index]
           [--apply] [--no-add] [--build-fake-ancestor &lt;file&gt;] [-R | --reverse]
           [--allow-binary-replacement | --binary] [--reject] [-z]
-          [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
+          [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
           [--whitespace=&lt;nowarn|warn|fix|error|error-all&gt;]
           [--exclude=PATH] [--verbose] [&lt;patch&gt;&#8230;]</div></div>
 </div>
@@ -368,7 +368,7 @@ and a work tree.</p>
 </dt>
 <dd>
 <p>
-        Newer git-diff output has embedded <em>index information</em>
+        Newer <tt>git-diff</tt> output has embedded <em>index information</em>
         for each blob to help identify the original version that
         the patch applies to.  When this flag is given, and if
         the original versions of the blobs is available locally,
@@ -393,7 +393,7 @@ the information is read from the current index instead.</p>
 </dt>
 <dd>
 <p>
-        For atomicity, <a href="git-apply.html">git-apply(1)</a> by default fails the whole patch and
+        For atomicity, <tt>git-apply</tt> by default fails the whole patch and
         does not touch the working tree when some of the hunks
         do not apply.  This option makes it apply
         the parts of the patch that are applicable, and leave the
@@ -437,7 +437,7 @@ the information is read from the current index instead.</p>
 </dt>
 <dd>
 <p>
-        By default, <a href="git-apply.html">git-apply(1)</a> expects that the patch being
+        By default, <tt>git-apply</tt> expects that the patch being
         applied is a unified diff with at least one line of context.
         This provides good safety measures, but breaks down when
         applying a diff generated with --unified=0. To bypass these
@@ -452,7 +452,7 @@ discouraged.</p>
 <dd>
 <p>
         If you use any of the options marked "Turns off
-        <em>apply</em>" above, <a href="git-apply.html">git-apply(1)</a> reads and outputs the
+        <em>apply</em>" above, <tt>git-apply</tt> reads and outputs the
         information you asked without actually applying the
         patch.  Give this flag after those flags to also apply
         the patch.
@@ -508,8 +508,8 @@ discouraged.</p>
         considered whitespace errors.
 </p>
 <p>By default, the command outputs warning messages but applies the patch.
-When <a href="git-apply.html">git-apply(1)</a> is used for statistics and not applying a
-patch, it defaults to <tt>nowarn</tt>.</p>
+When <tt>git-apply is used for statistics and not applying a
+patch, it defaults to `nowarn</tt>.</p>
 <p>You can use different <tt>&lt;action&gt;</tt> to control this
 behavior:</p>
 <ul>
@@ -570,6 +570,16 @@ behavior:</p>
         additional information to be reported.
 </p>
 </dd>
+<dt>
+--recount
+</dt>
+<dd>
+<p>
+        Do not trust the line counts in the hunk headers, but infer them
+        by inspecting the patch (e.g. after editing the patch without
+        adjusting the hunk headers appropriately).
+</p>
+</dd>
 </dl>
 </div>
 <h2>Configuration</h2>
@@ -588,7 +598,7 @@ apply.whitespace
 </div>
 <h2>Submodules</h2>
 <div class="sectionbody">
-<p>If the patch contains any changes to submodules then <a href="git-apply.html">git-apply(1)</a>
+<p>If the patch contains any changes to submodules then <tt>git-apply</tt>
 treats these changes as follows.</p>
 <p>If --index is specified (explicitly or implicitly), then the submodule
 commits must match the index exactly for the patch to apply.  If any
@@ -613,7 +623,7 @@ subdirectory is checked and (if possible) updated.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:18 UTC
+Last updated 02-Jul-2008 03:01:32 UTC
 </div>
 </div>
 </body>
diff --git a/git-apply.txt b/git-apply.txt
index c8347637d..70d19f63e 100644
--- a/git-apply.txt
+++ b/git-apply.txt
@@ -9,10 +9,10 @@ git-apply - Apply a patch on a git index file and a working tree
 SYNOPSIS
 --------
 [verse]
-'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
+'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
 	  [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
 	  [--allow-binary-replacement | --binary] [--reject] [-z]
-	  [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
+	  [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
 	  [--whitespace=<nowarn|warn|fix|error|error-all>]
 	  [--exclude=PATH] [--verbose] [<patch>...]
 
@@ -64,7 +64,7 @@ OPTIONS
 	without using the working tree. This implies '--index'.
 
 --build-fake-ancestor <file>::
-	Newer git-diff output has embedded 'index information'
+	Newer `git-diff` output has embedded 'index information'
 	for each blob to help identify the original version that
 	the patch applies to.  When this flag is given, and if
 	the original versions of the blobs is available locally,
@@ -78,7 +78,7 @@ the information is read from the current index instead.
 	Apply the patch in reverse.
 
 --reject::
-	For atomicity, linkgit:git-apply[1] by default fails the whole patch and
+	For atomicity, `git-apply` by default fails the whole patch and
 	does not touch the working tree when some of the hunks
 	do not apply.  This option makes it apply
 	the parts of the patch that are applicable, and leave the
@@ -102,7 +102,7 @@ the information is read from the current index instead.
 	ever ignored.
 
 --unidiff-zero::
-	By default, linkgit:git-apply[1] expects that the patch being
+	By default, `git-apply` expects that the patch being
 	applied is a unified diff with at least one line of context.
 	This provides good safety measures, but breaks down when
 	applying a diff generated with --unified=0. To bypass these
@@ -113,7 +113,7 @@ discouraged.
 
 --apply::
 	If you use any of the options marked "Turns off
-	'apply'" above, linkgit:git-apply[1] reads and outputs the
+	'apply'" above, `git-apply` reads and outputs the
 	information you asked without actually applying the
 	patch.  Give this flag after those flags to also apply
 	the patch.
@@ -147,7 +147,7 @@ discouraged.
 	considered whitespace errors.
 +
 By default, the command outputs warning messages but applies the patch.
-When linkgit:git-apply[1] is used for statistics and not applying a
+When `git-apply is used for statistics and not applying a
 patch, it defaults to `nowarn`.
 +
 You can use different `<action>` to control this
@@ -177,6 +177,11 @@ behavior:
 	current patch being applied will be printed. This option will cause
 	additional information to be reported.
 
+--recount::
+	Do not trust the line counts in the hunk headers, but infer them
+	by inspecting the patch (e.g. after editing the patch without
+	adjusting the hunk headers appropriately).
+
 Configuration
 -------------
 
@@ -186,7 +191,7 @@ apply.whitespace::
 
 Submodules
 ----------
-If the patch contains any changes to submodules then linkgit:git-apply[1]
+If the patch contains any changes to submodules then `git-apply`
 treats these changes as follows.
 
 If --index is specified (explicitly or implicitly), then the submodule
diff --git a/git-archimport.html b/git-archimport.html
index e4e58177d..d2f8c36b0 100644
--- a/git-archimport.html
+++ b/git-archimport.html
@@ -273,7 +273,7 @@ git-archimport(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-archimport</em> [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+<div class="content"><em>git archimport</em> [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
                &lt;archive/branch&gt;[:&lt;git-branch&gt;] &#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -294,11 +294,11 @@ import.</p>
 Arch repository.
 Make sure you have a recent version of <tt>tla</tt> available in the path. <tt>tla</tt> must
 know about the repositories you pass to <tt>git-archimport</tt>.</p>
-<p>For the initial import <tt>git-archimport</tt> expects to find itself in an empty
+<p>For the initial import, <tt>git-archimport</tt> expects to find itself in an empty
 directory. To follow the development of a project that uses Arch, rerun
 <tt>git-archimport</tt> with the same parameters as the initial import to perform
 incremental imports.</p>
-<p>While git-archimport will try to create sensible branch names for the
+<p>While <tt>git-archimport</tt> will try to create sensible branch names for the
 archives that it imports, it is also possible to specify git branch names
 manually.  To do so, write a git branch name after each &lt;archive/branch&gt;
 parameter, separated by a colon.  This way, you can shorten the Arch
@@ -364,7 +364,7 @@ patches that have been traded out-of-sequence between the branches.</p>
 <dd>
 <p>
         Use this for compatibility with old-style branch names used by
-        earlier versions of git-archimport.  Old-style branch names
+        earlier versions of <tt>git-archimport</tt>.  Old-style branch names
         were category--branch, whereas new-style branch names are
         archive,category--branch--version.  In both cases, names given
         on the command-line will override the automatically-generated
@@ -422,7 +422,7 @@ patches that have been traded out-of-sequence between the branches.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:20 UTC
+Last updated 02-Jul-2008 03:01:32 UTC
 </div>
 </div>
 </body>
diff --git a/git-archimport.txt b/git-archimport.txt
index 603117c79..f089debaa 100644
--- a/git-archimport.txt
+++ b/git-archimport.txt
@@ -9,7 +9,7 @@ git-archimport - Import an Arch repository into git
 SYNOPSIS
 --------
 [verse]
-'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
+'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
                <archive/branch>[:<git-branch>] ...
 
 DESCRIPTION
@@ -34,12 +34,12 @@ Arch repository.
 Make sure you have a recent version of `tla` available in the path. `tla` must
 know about the repositories you pass to `git-archimport`.
 
-For the initial import `git-archimport` expects to find itself in an empty
+For the initial import, `git-archimport` expects to find itself in an empty
 directory. To follow the development of a project that uses Arch, rerun
 `git-archimport` with the same parameters as the initial import to perform
 incremental imports.
 
-While git-archimport will try to create sensible branch names for the
+While `git-archimport` will try to create sensible branch names for the
 archives that it imports, it is also possible to specify git branch names
 manually.  To do so, write a git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
@@ -84,7 +84,7 @@ OPTIONS
 
 -o::
 	Use this for compatibility with old-style branch names used by
-	earlier versions of git-archimport.  Old-style branch names
+	earlier versions of `git-archimport`.  Old-style branch names
 	were category--branch, whereas new-style branch names are
 	archive,category--branch--version.  In both cases, names given
 	on the command-line will override the automatically-generated
diff --git a/git-archive.html b/git-archive.html
index 614551a25..b9549703e 100644
--- a/git-archive.html
+++ b/git-archive.html
@@ -273,7 +273,7 @@ git-archive(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-archive</em> --format=&lt;fmt&gt; [--list] [--prefix=&lt;prefix&gt;/] [&lt;extra&gt;]
+<div class="content"><em>git archive</em> --format=&lt;fmt&gt; [--list] [--prefix=&lt;prefix&gt;/] [&lt;extra&gt;]
               [--remote=&lt;repo&gt; [--exec=&lt;git-upload-archive&gt;]] &lt;tree-ish&gt;
               [path&#8230;]</div></div>
 </div>
@@ -283,13 +283,13 @@ git-archive(1) Manual Page
 structure for the named tree, and writes it out to the standard
 output.  If &lt;prefix&gt; is specified it is
 prepended to the filenames in the archive.</p>
-<p><em>git-archive</em> behaves differently when given a tree ID versus when
+<p><tt>git-archive</tt> behaves differently when given a tree ID versus when
 given a commit ID or tag ID.  In the first case the current time is
 used as modification time of each file in the archive.  In the latter
 case the commit time as recorded in the referenced commit object is
 used instead.  Additionally the commit ID is stored in a global
 extended pax header if the tar format is used; it can be extracted
-using <em>git-get-tar-commit-id</em>. In ZIP files it is stored as a file
+using <tt>git-get-tar-commit-id</tt>. In ZIP files it is stored as a file
 comment.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -358,7 +358,7 @@ comment.</p>
 <dd>
 <p>
         Used with --remote to specify the path to the
-        git-upload-archive executable on the remote side.
+        <tt>git-upload-archive</tt> on the remote side.
 </p>
 </dd>
 <dt>
@@ -475,7 +475,7 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ &gt; git-1.4.0-d
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:19 UTC
+Last updated 02-Jul-2008 03:01:32 UTC
 </div>
 </div>
 </body>
diff --git a/git-archive.txt b/git-archive.txt
index 9b5f3ae5e..dbe9bad2f 100644
--- a/git-archive.txt
+++ b/git-archive.txt
@@ -9,7 +9,7 @@ git-archive - Create an archive of files from a named tree
 SYNOPSIS
 --------
 [verse]
-'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
+'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
 	      [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
 	      [path...]
 
@@ -20,13 +20,13 @@ structure for the named tree, and writes it out to the standard
 output.  If <prefix> is specified it is
 prepended to the filenames in the archive.
 
-'git-archive' behaves differently when given a tree ID versus when
+`git-archive` behaves differently when given a tree ID versus when
 given a commit ID or tag ID.  In the first case the current time is
 used as modification time of each file in the archive.  In the latter
 case the commit time as recorded in the referenced commit object is
 used instead.  Additionally the commit ID is stored in a global
 extended pax header if the tar format is used; it can be extracted
-using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
+using `git-get-tar-commit-id`. In ZIP files it is stored as a file
 comment.
 
 OPTIONS
@@ -57,7 +57,7 @@ OPTIONS
 
 --exec=<git-upload-archive>::
 	Used with --remote to specify the path to the
-	git-upload-archive executable on the remote side.
+	`git-upload-archive` on the remote side.
 
 <tree-ish>::
 	The tree or commit to produce an archive for.
diff --git a/git-bisect.html b/git-bisect.html
index 5d8309af8..0a39d974c 100644
--- a/git-bisect.html
+++ b/git-bisect.html
@@ -291,7 +291,7 @@ git bisect replay &lt;logfile&gt;
 git bisect log
 git bisect run &lt;cmd&gt;...</tt></pre>
 </div></div>
-<p>This command uses <em>git-rev-list --bisect</em> option to help drive the
+<p>This command uses <tt>git rev-list --bisect</tt> to help drive the
 binary search process to find which change introduced a bug, given an
 old "good" commit object name and a later "bad" commit object name.</p>
 <h3>Getting help</h3>
@@ -434,13 +434,13 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
 "revision that does not have this commit needs this patch applied to
 work around other problem this bisection is not interested in")
 applied to the revision being tested.</p>
-<p>To cope with such a situation, after the inner git-bisect finds the
+<p>To cope with such a situation, after the inner <tt>git-bisect</tt> finds the
 next revision to test, with the "run" script, you can apply that tweak
 before compiling, run the real test, and after the test decides if the
 revision (possibly with the needed tweaks) passed the test, rewind the
 tree to the pristine state.  Finally the "run" script can exit with
-the status of the real test to let "git bisect run" command loop to
-know the outcome.</p>
+the status of the real test to let the "git bisect run" command loop to
+determine the outcome.</p>
 </div>
 <h2>EXAMPLES</h2>
 <div class="sectionbody">
@@ -511,7 +511,7 @@ test processes and the scripts.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 15-Jun-2008 05:10:05 UTC
+Last updated 02-Jul-2008 03:01:32 UTC
 </div>
 </div>
 </body>
diff --git a/git-bisect.txt b/git-bisect.txt
index 3ca0d330a..8bbcb940f 100644
--- a/git-bisect.txt
+++ b/git-bisect.txt
@@ -26,7 +26,7 @@ on the subcommand:
  git bisect log
  git bisect run <cmd>...
 
-This command uses 'git-rev-list --bisect' option to help drive the
+This command uses `git rev-list --bisect` to help drive the
 binary search process to find which change introduced a bug, given an
 old "good" commit object name and a later "bad" commit object name.
 
@@ -215,13 +215,13 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
 work around other problem this bisection is not interested in")
 applied to the revision being tested.
 
-To cope with such a situation, after the inner git-bisect finds the
+To cope with such a situation, after the inner `git-bisect` finds the
 next revision to test, with the "run" script, you can apply that tweak
 before compiling, run the real test, and after the test decides if the
 revision (possibly with the needed tweaks) passed the test, rewind the
 tree to the pristine state.  Finally the "run" script can exit with
-the status of the real test to let "git bisect run" command loop to
-know the outcome.
+the status of the real test to let the "git bisect run" command loop to
+determine the outcome.
 
 EXAMPLES
 --------
diff --git a/git-blame.html b/git-blame.html
index 8dc36ec09..84a08c4d2 100644
--- a/git-blame.html
+++ b/git-blame.html
@@ -273,7 +273,7 @@ git-blame(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-blame</em> [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
+<div class="content"><em>git blame</em> [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
             [-S &lt;revs-file&gt;] [-M] [-C] [-C] [--since=&lt;date&gt;]
             [&lt;rev&gt; | --contents &lt;file&gt;] [--] &lt;file&gt;</div></div>
 </div>
@@ -283,7 +283,7 @@ git-blame(1) Manual Page
 last modified the line. Optionally, start annotating from the given revision.</p>
 <p>Also it can limit the range of lines annotated.</p>
 <p>This report doesn't tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as <a href="git-diff.html">git-diff(1)</a> or the "pickaxe"
+replaced; you need to use a tool such as <tt>git-diff</tt> or the "pickaxe"
 interface briefly mentioned in the following paragraph.</p>
 <p>Apart from supporting file annotation, git also supports searching the
 development history for when a code snippet occurred in a change. This makes it
@@ -480,7 +480,7 @@ commit.</p>
         file (see <tt>-M</tt>).  The first number listed is the score.
         This is the number of alphanumeric characters detected
         to be moved between or within files.  This must be above
-        a certain threshold for git-blame to consider those lines
+        a certain threshold for <tt>git-blame</tt> to consider those lines
         of code to have been moved.
 </p>
 </dd>
@@ -698,7 +698,7 @@ commit commentary), a blame viewer won't ever care.</td>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:19 UTC
+Last updated 02-Jul-2008 03:01:33 UTC
 </div>
 </div>
 </body>
diff --git a/git-blame.txt b/git-blame.txt
index 8f4fb4668..443039fd9 100644
--- a/git-blame.txt
+++ b/git-blame.txt
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
 SYNOPSIS
 --------
 [verse]
-'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
+'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
             [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
             [<rev> | --contents <file>] [--] <file>
 
@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
 Also it can limit the range of lines annotated.
 
 This report doesn't tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as linkgit:git-diff[1] or the "pickaxe"
+replaced; you need to use a tool such as `git-diff` or the "pickaxe"
 interface briefly mentioned in the following paragraph.
 
 Apart from supporting file annotation, git also supports searching the
@@ -49,7 +49,7 @@ include::blame-options.txt[]
 	file (see `-M`).  The first number listed is the score.
 	This is the number of alphanumeric characters detected
 	to be moved between or within files.  This must be above
-	a certain threshold for git-blame to consider those lines
+	a certain threshold for `git-blame` to consider those lines
 	of code to have been moved.
 
 -f::
diff --git a/git-branch.html b/git-branch.html
index 59bb85d54..2c1f8878e 100644
--- a/git-branch.html
+++ b/git-branch.html
@@ -273,12 +273,12 @@ git-branch(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-branch</em> [--color | --no-color] [-r | -a] [--merged | --no-merged]
+<div class="content"><em>git branch</em> [--color | --no-color] [-r | -a] [--merged | --no-merged]
            [-v [--abbrev=&lt;length&gt; | --no-abbrev]]
            [--contains &lt;commit&gt;]
-<em>git-branch</em> [--track | --no-track] [-l] [-f] &lt;branchname&gt; [&lt;start-point&gt;]
-<em>git-branch</em> (-m | -M) [&lt;oldbranch&gt;] &lt;newbranch&gt;
-<em>git-branch</em> (-d | -D) [-r] &lt;branchname&gt;&#8230;</div></div>
+<em>git branch</em> [--track | --no-track] [-l] [-f] &lt;branchname&gt; [&lt;start-point&gt;]
+<em>git branch</em> (-m | -M) [&lt;oldbranch&gt;] &lt;newbranch&gt;
+<em>git branch</em> (-d | -D) [-r] &lt;branchname&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -299,7 +299,7 @@ equal to that of the currently checked out branch.</p>
 working tree to it; use "git checkout &lt;newbranch&gt;" to switch to the
 new branch.</p>
 <p>When a local branch is started off a remote branch, git sets up the
-branch so that <a href="git-pull.html">git-pull(1)</a> will appropriately merge from
+branch so that <tt>git-pull</tt> will appropriately merge from
 the remote branch. This behavior may be changed via the global
 <tt>branch.autosetupmerge</tt> configuration flag. That setting can be
 overridden by using the <tt>--track</tt> and <tt>--no-track</tt> options.</p>
@@ -313,7 +313,7 @@ specify more than one branch for deletion.  If the branch currently
 has a reflog then the reflog will also be deleted.</p>
 <p>Use -r together with -d to delete remote-tracking branches. Note, that it
 only makes sense to delete remote-tracking branches if they no longer exist
-in remote repository or if <a href="git-fetch.html">git-fetch(1)</a> was configured not to fetch
+in remote repository or if <tt>git-fetch</tt> was configured not to fetch
 them again. See also <em>prune</em> subcommand of <a href="git-remote.html">git-remote(1)</a> for way to
 clean up all obsolete remote-tracking branches.</p>
 </div>
@@ -437,14 +437,14 @@ clean up all obsolete remote-tracking branches.</p>
 </dt>
 <dd>
 <p>
-        When creating a new branch, set up configuration so that git-pull
+        When creating a new branch, set up configuration so that <tt>git-pull</tt>
         will automatically retrieve data from the start point, which must be
         a branch. Use this if you always pull from the same upstream branch
         into the new branch, and if you don't want to use "git pull
         &lt;repository&gt; &lt;refspec&gt;" explicitly. This behavior is the default
         when the start point is a remote branch. Set the
         branch.autosetupmerge configuration variable to <tt>false</tt> if you want
-        git-checkout and git-branch to always behave as if <em>--no-track</em> were
+        <tt>git-checkout</tt> and <tt>git-branch</tt> to always behave as if <em>--no-track</em> were
         given. Set it to <tt>always</tt> if you want this behavior when the
         start-point is either a local or remote branch.
 </p>
@@ -616,7 +616,7 @@ but different purposes:</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:20 UTC
+Last updated 02-Jul-2008 03:01:33 UTC
 </div>
 </div>
 </body>
diff --git a/git-branch.txt b/git-branch.txt
index 0fd58083e..5e78aed7d 100644
--- a/git-branch.txt
+++ b/git-branch.txt
@@ -8,12 +8,12 @@ git-branch - List, create, or delete branches
 SYNOPSIS
 --------
 [verse]
-'git-branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
+'git branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
 	   [-v [--abbrev=<length> | --no-abbrev]]
 	   [--contains <commit>]
-'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
-'git-branch' (-m | -M) [<oldbranch>] <newbranch>
-'git-branch' (-d | -D) [-r] <branchname>...
+'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git branch' (-m | -M) [<oldbranch>] <newbranch>
+'git branch' (-d | -D) [-r] <branchname>...
 
 DESCRIPTION
 -----------
@@ -37,7 +37,7 @@ working tree to it; use "git checkout <newbranch>" to switch to the
 new branch.
 
 When a local branch is started off a remote branch, git sets up the
-branch so that linkgit:git-pull[1] will appropriately merge from
+branch so that `git-pull` will appropriately merge from
 the remote branch. This behavior may be changed via the global
 `branch.autosetupmerge` configuration flag. That setting can be
 overridden by using the `--track` and `--no-track` options.
@@ -54,7 +54,7 @@ has a reflog then the reflog will also be deleted.
 
 Use -r together with -d to delete remote-tracking branches. Note, that it
 only makes sense to delete remote-tracking branches if they no longer exist
-in remote repository or if linkgit:git-fetch[1] was configured not to fetch
+in remote repository or if `git-fetch` was configured not to fetch
 them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
 clean up all obsolete remote-tracking branches.
 
@@ -107,14 +107,14 @@ OPTIONS
 	Display the full sha1s in output listing rather than abbreviating them.
 
 --track::
-	When creating a new branch, set up configuration so that git-pull
+	When creating a new branch, set up configuration so that `git-pull`
 	will automatically retrieve data from the start point, which must be
 	a branch. Use this if you always pull from the same upstream branch
 	into the new branch, and if you don't want to use "git pull
 	<repository> <refspec>" explicitly. This behavior is the default
 	when the start point is a remote branch. Set the
 	branch.autosetupmerge configuration variable to `false` if you want
-	git-checkout and git-branch to always behave as if '--no-track' were
+	`git-checkout` and `git-branch` to always behave as if '--no-track' were
 	given. Set it to `always` if you want this behavior when the
 	start-point is either a local or remote branch.
 
diff --git a/git-bundle.html b/git-bundle.html
index 8fafa5859..3ec368b7e 100644
--- a/git-bundle.html
+++ b/git-bundle.html
@@ -273,10 +273,10 @@ git-bundle(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-bundle</em> create &lt;file&gt; &lt;git-rev-list args&gt;
-<em>git-bundle</em> verify &lt;file&gt;
-<em>git-bundle</em> list-heads &lt;file&gt; [refname&#8230;]
-<em>git-bundle</em> unbundle &lt;file&gt; [refname&#8230;]</div></div>
+<div class="content"><em>git bundle</em> create &lt;file&gt; &lt;git-rev-list args&gt;
+<em>git bundle</em> verify &lt;file&gt;
+<em>git bundle</em> list-heads &lt;file&gt; [refname&#8230;]
+<em>git bundle</em> unbundle &lt;file&gt; [refname&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -284,9 +284,9 @@ git-bundle(1) Manual Page
 machine be replicated on another machine, but the two machines cannot
 be directly connected so the interactive git protocols (git, ssh,
 rsync, http) cannot be used.  This command provides support for
-git-fetch and git-pull to operate by packaging objects and references
+<tt>git-fetch</tt> and <tt>git-pull</tt> to operate by packaging objects and references
 in an archive at the originating machine, then importing those into
-another repository using <a href="git-fetch.html">git-fetch(1)</a> and <a href="git-pull.html">git-pull(1)</a>
+another repository using <tt>git-fetch</tt> and <tt>git-pull</tt>
 after moving the archive by some means (i.e., by sneakernet).  As no
 direct connection between repositories exists, the user must specify a
 basis for the bundle that is held by the destination repository: the
@@ -302,7 +302,7 @@ create &lt;file&gt;
 <dd>
 <p>
        Used to create a bundle named <em>file</em>.  This requires the
-       git-rev-list arguments to define the bundle contents.
+       <tt>git-rev-list</tt> arguments to define the bundle contents.
 </p>
 </dd>
 <dt>
@@ -314,7 +314,7 @@ verify &lt;file&gt;
        cleanly to the current repository.  This includes checks on the
        bundle format itself as well as checking that the prerequisite
        commits exist and are fully linked in the current repository.
-       git-bundle prints a list of missing commits, if any, and exits
+       <tt>git-bundle</tt> prints a list of missing commits, if any, and exits
        with non-zero status.
 </p>
 </dd>
@@ -333,12 +333,11 @@ unbundle &lt;file&gt;
 </dt>
 <dd>
 <p>
-       Passes the objects in the bundle to <a href="git-index-pack.html">git-index-pack(1)</a>
+       Passes the objects in the bundle to <tt>git-index-pack</tt>
        for storage in the repository, then prints the names of all
        defined references. If a reflist is given, only references
        matching those in the given list are printed. This command is
-       really plumbing, intended to be called only by
-       <a href="git-fetch.html">git-fetch(1)</a>.
+       really plumbing, intended to be called only by <tt>git-fetch</tt>.
 </p>
 </dd>
 <dt>
@@ -346,8 +345,8 @@ unbundle &lt;file&gt;
 </dt>
 <dd>
 <p>
-       A list of arguments, acceptable to git-rev-parse and
-       git-rev-list, that specify the specific objects and references
+       A list of arguments, acceptable to <tt>git-rev-parse</tt> and
+       <tt>git-rev-list</tt>, that specify the specific objects and references
        to transport.  For example, "master~10..master" causes the
        current master reference to be packaged along with all objects
        added since its 10th ancestor commit.  There is no explicit
@@ -361,18 +360,18 @@ unbundle &lt;file&gt;
 <dd>
 <p>
        A list of references used to limit the references reported as
-       available. This is principally of use to git-fetch, which
+       available. This is principally of use to <tt>git-fetch</tt>, which
        expects to receive only those references asked for and not
-       necessarily everything in the pack (in this case, git-bundle is
-       acting like <a href="git-fetch-pack.html">git-fetch-pack(1)</a>).
+       necessarily everything in the pack (in this case, <tt>git-bundle</tt> is
+       acting like <tt>git-fetch-pack</tt>).
 </p>
 </dd>
 </dl>
 </div>
 <h2>SPECIFYING REFERENCES</h2>
 <div class="sectionbody">
-<p>git-bundle will only package references that are shown by
-git-show-ref: this includes heads, tags, and remote heads.  References
+<p><tt>git-bundle</tt> will only package references that are shown by
+<tt>git-show-ref</tt>: this includes heads, tags, and remote heads.  References
 such as master~1 cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
@@ -414,7 +413,7 @@ and move it afterwards to help build the bundle.</p>
 </ul>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-bundle create mybundle master ^lastR2bundle
+<pre><tt>$ git bundle create mybundle master ^lastR2bundle
 $ git tag -f lastR2bundle master</tt></pre>
 </div></div>
 <ul>
@@ -453,8 +452,8 @@ With a limit on the number of commits
 <p>Then you move mybundle from A to B, and in R2 on B:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-bundle verify mybundle
-$ git-fetch mybundle master:localRef</tt></pre>
+<pre><tt>$ git bundle verify mybundle
+$ git fetch mybundle master:localRef</tt></pre>
 </div></div>
 <p>With something like this in the config in R2:</p>
 <div class="listingblock">
@@ -484,7 +483,7 @@ network.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:22 UTC
+Last updated 02-Jul-2008 03:01:33 UTC
 </div>
 </div>
 </body>
diff --git a/git-bundle.txt b/git-bundle.txt
index f6a06129a..b729db7d2 100644
--- a/git-bundle.txt
+++ b/git-bundle.txt
@@ -9,10 +9,10 @@ git-bundle - Move objects and refs by archive
 SYNOPSIS
 --------
 [verse]
-'git-bundle' create <file> <git-rev-list args>
-'git-bundle' verify <file>
-'git-bundle' list-heads <file> [refname...]
-'git-bundle' unbundle <file> [refname...]
+'git bundle' create <file> <git-rev-list args>
+'git bundle' verify <file>
+'git bundle' list-heads <file> [refname...]
+'git bundle' unbundle <file> [refname...]
 
 DESCRIPTION
 -----------
@@ -21,9 +21,9 @@ Some workflows require that one or more branches of development on one
 machine be replicated on another machine, but the two machines cannot
 be directly connected so the interactive git protocols (git, ssh,
 rsync, http) cannot be used.  This command provides support for
-git-fetch and git-pull to operate by packaging objects and references
+`git-fetch` and `git-pull` to operate by packaging objects and references
 in an archive at the originating machine, then importing those into
-another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
+another repository using `git-fetch` and `git-pull`
 after moving the archive by some means (i.e., by sneakernet).  As no
 direct connection between repositories exists, the user must specify a
 basis for the bundle that is held by the destination repository: the
@@ -35,14 +35,14 @@ OPTIONS
 
 create <file>::
        Used to create a bundle named 'file'.  This requires the
-       git-rev-list arguments to define the bundle contents.
+       `git-rev-list` arguments to define the bundle contents.
 
 verify <file>::
        Used to check that a bundle file is valid and will apply
        cleanly to the current repository.  This includes checks on the
        bundle format itself as well as checking that the prerequisite
        commits exist and are fully linked in the current repository.
-       git-bundle prints a list of missing commits, if any, and exits
+       `git-bundle` prints a list of missing commits, if any, and exits
        with non-zero status.
 
 list-heads <file>::
@@ -51,16 +51,15 @@ list-heads <file>::
        printed out.
 
 unbundle <file>::
-       Passes the objects in the bundle to linkgit:git-index-pack[1]
+       Passes the objects in the bundle to `git-index-pack`
        for storage in the repository, then prints the names of all
        defined references. If a reflist is given, only references
        matching those in the given list are printed. This command is
-       really plumbing, intended to be called only by
-       linkgit:git-fetch[1].
+       really plumbing, intended to be called only by `git-fetch`.
 
 [git-rev-list-args...]::
-       A list of arguments, acceptable to git-rev-parse and
-       git-rev-list, that specify the specific objects and references
+       A list of arguments, acceptable to `git-rev-parse` and
+       `git-rev-list`, that specify the specific objects and references
        to transport.  For example, "master~10..master" causes the
        current master reference to be packaged along with all objects
        added since its 10th ancestor commit.  There is no explicit
@@ -70,16 +69,16 @@ unbundle <file>::
 
 [refname...]::
        A list of references used to limit the references reported as
-       available. This is principally of use to git-fetch, which
+       available. This is principally of use to `git-fetch`, which
        expects to receive only those references asked for and not
-       necessarily everything in the pack (in this case, git-bundle is
-       acting like linkgit:git-fetch-pack[1]).
+       necessarily everything in the pack (in this case, `git-bundle` is
+       acting like `git-fetch-pack`).
 
 SPECIFYING REFERENCES
 ---------------------
 
-git-bundle will only package references that are shown by
-git-show-ref: this includes heads, tags, and remote heads.  References
+`git-bundle` will only package references that are shown by
+`git-show-ref`: this includes heads, tags, and remote heads.  References
 such as master~1 cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
@@ -116,7 +115,7 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
 and move it afterwards to help build the bundle.
 
 ------------
-$ git-bundle create mybundle master ^lastR2bundle
+$ git bundle create mybundle master ^lastR2bundle
 $ git tag -f lastR2bundle master
 ------------
 
@@ -141,8 +140,8 @@ $ git bundle create mybundle master -n 10
 Then you move mybundle from A to B, and in R2 on B:
 
 ------------
-$ git-bundle verify mybundle
-$ git-fetch mybundle master:localRef
+$ git bundle verify mybundle
+$ git fetch mybundle master:localRef
 ------------
 
 With something like this in the config in R2:
diff --git a/git-cat-file.html b/git-cat-file.html
index ba07cd5b0..6e6300843 100644
--- a/git-cat-file.html
+++ b/git-cat-file.html
@@ -273,8 +273,8 @@ git-cat-file(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-cat-file</em> [-t | -s | -e | -p | &lt;type&gt;] &lt;object&gt;
-<em>git-cat-file</em> [--batch | --batch-check] &lt; &lt;list-of-objects&gt;</div></div>
+<div class="content"><em>git cat-file</em> [-t | -s | -e | -p | &lt;type&gt;] &lt;object&gt;
+<em>git cat-file</em> [--batch | --batch-check] &lt; &lt;list-of-objects&gt;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -407,7 +407,7 @@ for each object specified on stdin that does not exist in the repository:</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 11-Jun-2008 07:52:11 UTC
+Last updated 02-Jul-2008 03:01:34 UTC
 </div>
 </div>
 </body>
diff --git a/git-cat-file.txt b/git-cat-file.txt
index f58013ca6..d35e8a04f 100644
--- a/git-cat-file.txt
+++ b/git-cat-file.txt
@@ -9,8 +9,8 @@ git-cat-file - Provide content or type/size information for repository objects
 SYNOPSIS
 --------
 [verse]
-'git-cat-file' [-t | -s | -e | -p | <type>] <object>
-'git-cat-file' [--batch | --batch-check] < <list-of-objects>
+'git cat-file' [-t | -s | -e | -p | <type>] <object>
+'git cat-file' [--batch | --batch-check] < <list-of-objects>
 
 DESCRIPTION
 -----------
diff --git a/git-check-attr.html b/git-check-attr.html
index 5819a908d..b11c6d868 100644
--- a/git-check-attr.html
+++ b/git-check-attr.html
@@ -272,7 +272,7 @@ git-check-attr(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-check-attr</em> attr&#8230; [--] pathname&#8230;</p>
+<p><em>git check-attr</em> attr&#8230; [--] pathname&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -312,7 +312,7 @@ git-check-attr(1) Manual Page
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:23 UTC
+Last updated 02-Jul-2008 03:01:34 UTC
 </div>
 </div>
 </body>
diff --git a/git-check-attr.txt b/git-check-attr.txt
index ef16b9398..abe1f1b7d 100644
--- a/git-check-attr.txt
+++ b/git-check-attr.txt
@@ -8,7 +8,7 @@ git-check-attr - Display gitattributes information.
 
 SYNOPSIS
 --------
-'git-check-attr' attr... [--] pathname...
+'git check-attr' attr... [--] pathname...
 
 DESCRIPTION
 -----------
diff --git a/git-check-ref-format.html b/git-check-ref-format.html
index 72f664ffb..85c588a9e 100644
--- a/git-check-ref-format.html
+++ b/git-check-ref-format.html
@@ -272,7 +272,7 @@ git-check-ref-format(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-check-ref-format</em> &lt;refname&gt;</p>
+<p><em>git check-ref-format</em> &lt;refname&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -332,7 +332,7 @@ tilde <tt>~</tt> and caret <tt>&#94;</tt> are used to introduce postfix
 colon <tt>:</tt> is used as in <tt>srcref:dstref</tt> to mean "use srcref's
   value and store it in dstref" in fetch and push operations.
   It may also be used to select a specific object such as with
-  <a href="git-cat-file.html">git-cat-file(1)</a> "git-cat-file blob v1.3.3:refs.c".
+  <tt>git-cat-file</tt>: "git cat-file blob v1.3.3:refs.c".
 </p>
 </li>
 </ol>
@@ -343,7 +343,7 @@ colon <tt>:</tt> is used as in <tt>srcref:dstref</tt> to mean "use srcref's
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:25 UTC
+Last updated 02-Jul-2008 03:01:35 UTC
 </div>
 </div>
 </body>
diff --git a/git-check-ref-format.txt b/git-check-ref-format.txt
index c560c0aa6..429083bb6 100644
--- a/git-check-ref-format.txt
+++ b/git-check-ref-format.txt
@@ -7,7 +7,7 @@ git-check-ref-format - Make sure ref name is well formed
 
 SYNOPSIS
 --------
-'git-check-ref-format' <refname>
+'git check-ref-format' <refname>
 
 DESCRIPTION
 -----------
@@ -47,7 +47,7 @@ refname expressions (see linkgit:git-rev-parse[1]).  Namely:
 . colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
   value and store it in dstref" in fetch and push operations.
   It may also be used to select a specific object such as with
-  linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
+  `git-cat-file`: "git cat-file blob v1.3.3:refs.c".
 
 
 GIT
diff --git a/git-checkout-index.html b/git-checkout-index.html
index 748515a93..76e81a057 100644
--- a/git-checkout-index.html
+++ b/git-checkout-index.html
@@ -273,7 +273,7 @@ git-checkout-index(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-checkout-index</em> [-u] [-q] [-a] [-f] [-n] [--prefix=&lt;string&gt;]
+<div class="content"><em>git checkout-index</em> [-u] [-q] [-a] [-f] [-n] [--prefix=&lt;string&gt;]
                    [--stage=&lt;number&gt;|all]
                    [--temp]
                    [-z] [--stdin]
@@ -403,23 +403,23 @@ git-checkout-index(1) Manual Page
 </dd>
 </dl>
 <p>The order of the flags used to matter, but not anymore.</p>
-<p>Just doing <tt>git-checkout-index</tt> does nothing. You probably meant
-<tt>git-checkout-index -a</tt>. And if you want to force it, you want
-<tt>git-checkout-index -f -a</tt>.</p>
+<p>Just doing <tt>git checkout-index</tt> does nothing. You probably meant
+<tt>git checkout-index -a</tt>. And if you want to force it, you want
+<tt>git checkout-index -f -a</tt>.</p>
 <p>Intuitiveness is not the goal here. Repeatability is. The reason for
 the "no arguments means no work" behavior is that from scripts you are
 supposed to be able to do:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --</tt></pre>
+<pre><tt>$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --</tt></pre>
 </div></div>
 <p>which will force all existing <tt>*.h</tt> files to be replaced with their
 cached copies. If an empty command line implied "all", then this would
 force-refresh everything in the index, which was not the point.  But
-since git-checkout-index accepts --stdin it would be faster to use:</p>
+since <tt>git-checkout-index</tt> accepts --stdin it would be faster to use:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin</tt></pre>
+<pre><tt>$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin</tt></pre>
 </div></div>
 <p>The <tt>--</tt> is just a good idea when you know the rest will be filenames;
 it will prevent problems with a filename of, for example,  <tt>-a</tt>.
@@ -476,7 +476,7 @@ To update and refresh only the files already checked out
 <dd>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-checkout-index -n -f -a &amp;&amp; git-update-index --ignore-missing --refresh</tt></pre>
+<pre><tt>$ git checkout-index -n -f -a &amp;&amp; git update-index --ignore-missing --refresh</tt></pre>
 </div></div>
 </dd>
 <dt>
@@ -490,9 +490,9 @@ Using <tt>git-checkout-index</tt> to "export an entire tree"
 </p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-checkout-index --prefix=git-export-dir/ -a</tt></pre>
+<pre><tt>$ git checkout-index --prefix=git-export-dir/ -a</tt></pre>
 </div></div>
-<p><tt>git-checkout-index</tt> will "export" the index into the specified
+<p><tt>git checkout-index</tt> will "export" the index into the specified
 directory.</p>
 <p>The final "/" is important. The exported name is literally just
 prefixed with the specified string.  Contrast this with the
@@ -504,7 +504,7 @@ Export files with a prefix
 <dd>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-checkout-index --prefix=.merged- Makefile</tt></pre>
+<pre><tt>$ git checkout-index --prefix=.merged- Makefile</tt></pre>
 </div></div>
 <p>This will check out the currently cached copy of <tt>Makefile</tt>
 into the file <tt>.merged-Makefile</tt>.</p>
@@ -526,7 +526,7 @@ Junio C Hamano and the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:21 UTC
+Last updated 02-Jul-2008 03:01:34 UTC
 </div>
 </div>
 </body>
diff --git a/git-checkout-index.txt b/git-checkout-index.txt
index 676203b2e..a833a4dda 100644
--- a/git-checkout-index.txt
+++ b/git-checkout-index.txt
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
 SYNOPSIS
 --------
 [verse]
-'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
+'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
 		   [--stage=<number>|all]
 		   [--temp]
 		   [-z] [--stdin]
@@ -73,25 +73,25 @@ OPTIONS
 
 The order of the flags used to matter, but not anymore.
 
-Just doing `git-checkout-index` does nothing. You probably meant
-`git-checkout-index -a`. And if you want to force it, you want
-`git-checkout-index -f -a`.
+Just doing `git checkout-index` does nothing. You probably meant
+`git checkout-index -a`. And if you want to force it, you want
+`git checkout-index -f -a`.
 
 Intuitiveness is not the goal here. Repeatability is. The reason for
 the "no arguments means no work" behavior is that from scripts you are
 supposed to be able to do:
 
 ----------------
-$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
+$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
 ----------------
 
 which will force all existing `*.h` files to be replaced with their
 cached copies. If an empty command line implied "all", then this would
 force-refresh everything in the index, which was not the point.  But
-since git-checkout-index accepts --stdin it would be faster to use:
+since `git-checkout-index` accepts --stdin it would be faster to use:
 
 ----------------
-$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
+$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
 ----------------
 
 The `--` is just a good idea when you know the rest will be filenames;
@@ -144,7 +144,7 @@ EXAMPLES
 To update and refresh only the files already checked out::
 +
 ----------------
-$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
 ----------------
 
 Using `git-checkout-index` to "export an entire tree"::
@@ -153,10 +153,10 @@ Using `git-checkout-index` to "export an entire tree"::
 	Just read the desired tree into the index, and do:
 +
 ----------------
-$ git-checkout-index --prefix=git-export-dir/ -a
+$ git checkout-index --prefix=git-export-dir/ -a
 ----------------
 +
-`git-checkout-index` will "export" the index into the specified
+`git checkout-index` will "export" the index into the specified
 directory.
 +
 The final "/" is important. The exported name is literally just
@@ -166,7 +166,7 @@ following example.
 Export files with a prefix::
 +
 ----------------
-$ git-checkout-index --prefix=.merged- Makefile
+$ git checkout-index --prefix=.merged- Makefile
 ----------------
 +
 This will check out the currently cached copy of `Makefile`
diff --git a/git-checkout.html b/git-checkout.html
index bfad47f73..8765bef7c 100644
--- a/git-checkout.html
+++ b/git-checkout.html
@@ -273,8 +273,8 @@ git-checkout(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-checkout</em> [-q] [-f] [[--track | --no-track] -b &lt;new_branch&gt; [-l]] [-m] [&lt;branch&gt;]
-<em>git-checkout</em> [&lt;tree-ish&gt;] &lt;paths&gt;&#8230;</div></div>
+<div class="content"><em>git checkout</em> [-q] [-f] [[--track | --no-track] -b &lt;new_branch&gt; [-l]] [-m] [&lt;branch&gt;]
+<em>git checkout</em> [&lt;tree-ish&gt;] &lt;paths&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -286,7 +286,7 @@ be created; in this case you can use the --track or --no-track
 options, which will be passed to <tt>git branch</tt>.</p>
 <p>When &lt;paths&gt; are given, this command does <strong>not</strong> switch
 branches.  It updates the named paths in the working tree from
-the index file (i.e. it runs <tt>git-checkout-index -f -u</tt>), or
+the index file (i.e. it runs <tt>git checkout-index -f -u</tt>), or
 from a named commit.  In
 this case, the <tt>-f</tt> and <tt>-b</tt> options are meaningless and giving
 either of them results in an error.  &lt;tree-ish&gt; argument can be
@@ -333,14 +333,14 @@ working tree.</p>
 </dt>
 <dd>
 <p>
-        When creating a new branch, set up configuration so that git-pull
+        When creating a new branch, set up configuration so that <tt>git-pull</tt>
         will automatically retrieve data from the start point, which must be
         a branch. Use this if you always pull from the same upstream branch
         into the new branch, and if you don't want to use "git pull
         &lt;repository&gt; &lt;refspec&gt;" explicitly. This behavior is the default
         when the start point is a remote branch. Set the
         branch.autosetupmerge configuration variable to <tt>false</tt> if you want
-        git-checkout and git-branch to always behave as if <em>--no-track</em> were
+        <tt>git-checkout</tt> and <tt>git-branch</tt> to always behave as if <em>--no-track</em> were
         given. Set it to <tt>always</tt> if you want this behavior when the
         start-point is either a local or remote branch.
 </p>
@@ -418,7 +418,7 @@ version 1.5.0, the above command <em>detaches</em> your HEAD from the
 current branch and directly point at the commit named by the tag
 (<tt>v2.6.18</tt> in the above example).</p>
 <p>You can use usual git commands while in this state.  You can use
-<tt>git-reset --hard $othercommit</tt> to further move around, for
+<tt>git reset --hard $othercommit</tt> to further move around, for
 example.  You can make changes and create a new commit on top of
 a detached HEAD.  You can even create a merge by using <tt>git
 merge $othercommit</tt>.</p>
@@ -542,7 +542,7 @@ $ git add frotz</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:22 UTC
+Last updated 02-Jul-2008 03:01:34 UTC
 </div>
 </div>
 </body>
diff --git a/git-checkout.txt b/git-checkout.txt
index 3ad9760a4..c0f9c6e88 100644
--- a/git-checkout.txt
+++ b/git-checkout.txt
@@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
 SYNOPSIS
 --------
 [verse]
-'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
-'git-checkout' [<tree-ish>] <paths>...
+'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
+'git checkout' [<tree-ish>] <paths>...
 
 DESCRIPTION
 -----------
@@ -23,7 +23,7 @@ options, which will be passed to `git branch`.
 
 When <paths> are given, this command does *not* switch
 branches.  It updates the named paths in the working tree from
-the index file (i.e. it runs `git-checkout-index -f -u`), or
+the index file (i.e. it runs `git checkout-index -f -u`), or
 from a named commit.  In
 this case, the `-f` and `-b` options are meaningless and giving
 either of them results in an error.  <tree-ish> argument can be
@@ -49,14 +49,14 @@ OPTIONS
 
 -t::
 --track::
-	When creating a new branch, set up configuration so that git-pull
+	When creating a new branch, set up configuration so that `git-pull`
 	will automatically retrieve data from the start point, which must be
 	a branch. Use this if you always pull from the same upstream branch
 	into the new branch, and if you don't want to use "git pull
 	<repository> <refspec>" explicitly. This behavior is the default
 	when the start point is a remote branch. Set the
 	branch.autosetupmerge configuration variable to `false` if you want
-	git-checkout and git-branch to always behave as if '--no-track' were
+	`git-checkout` and `git-branch` to always behave as if '--no-track' were
 	given. Set it to `always` if you want this behavior when the
 	start-point is either a local or remote branch.
 
@@ -112,7 +112,7 @@ current branch and directly point at the commit named by the tag
 (`v2.6.18` in the above example).
 
 You can use usual git commands while in this state.  You can use
-`git-reset --hard $othercommit` to further move around, for
+`git reset --hard $othercommit` to further move around, for
 example.  You can make changes and create a new commit on top of
 a detached HEAD.  You can even create a merge by using `git
 merge $othercommit`.
diff --git a/git-cherry-pick.html b/git-cherry-pick.html
index 109760e2b..3dcec28fa 100644
--- a/git-cherry-pick.html
+++ b/git-cherry-pick.html
@@ -272,7 +272,7 @@ git-cherry-pick(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-cherry-pick</em> [--edit] [-n] [-m parent-number] [-s] [-x] &lt;commit&gt;</p>
+<p><em>git cherry-pick</em> [--edit] [-n] [-m parent-number] [-s] [-x] &lt;commit&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -289,7 +289,7 @@ modifications from the HEAD commit).</p>
 <dd>
 <p>
         Commit to cherry-pick.
-        For a more complete list of ways to spell commits, see
+        For a more complete list of ways to spell commits, see the
         "SPECIFYING REVISIONS" section in <a href="git-rev-parse.html">git-rev-parse(1)</a>.
 </p>
 </dd>
@@ -395,7 +395,7 @@ effect to your working tree in a row.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:23 UTC
+Last updated 02-Jul-2008 03:01:35 UTC
 </div>
 </div>
 </body>
diff --git a/git-cherry-pick.txt b/git-cherry-pick.txt
index 5ac9cfb0e..1b864dacf 100644
--- a/git-cherry-pick.txt
+++ b/git-cherry-pick.txt
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
 
 SYNOPSIS
 --------
-'git-cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
 
 DESCRIPTION
 -----------
@@ -19,7 +19,7 @@ OPTIONS
 -------
 <commit>::
 	Commit to cherry-pick.
-	For a more complete list of ways to spell commits, see
+	For a more complete list of ways to spell commits, see the
 	"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
 
 -e::
diff --git a/git-cherry.html b/git-cherry.html
index 7ebe67d7a..aa6f08438 100644
--- a/git-cherry.html
+++ b/git-cherry.html
@@ -272,14 +272,14 @@ git-cherry(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-cherry</em> [-v] &lt;upstream&gt; [&lt;head&gt;] [&lt;limit&gt;]</p>
+<p><em>git cherry</em> [-v] &lt;upstream&gt; [&lt;head&gt;] [&lt;limit&gt;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>The changeset (or "diff") of each commit between the fork-point and &lt;head&gt;
 is compared against each commit between the fork-point and &lt;upstream&gt;.
-The commits are compared with their <em>patch id</em>, obtained from <a href="git-patch-id.html">git-patch-id(1)</a>
-program.</p>
+The commits are compared with their <em>patch id</em>, obtained from
+the <tt>git-patch-id</tt> program.</p>
 <p>Every commit that doesn't exist in the &lt;upstream&gt; branch
 has its id (sha1) reported, prefixed by a symbol.  The ones that have
 equivalent change already
@@ -301,8 +301,8 @@ to and including &lt;limit&gt; are not reported:</p>
 fork-point
           \__*__*__&lt;limit&gt;__-__+__&gt; &lt;head&gt;</tt></pre>
 </div></div>
-<p>Because git-cherry compares the changeset rather than the commit id
-(sha1), you can use git-cherry to find out if a commit you made locally
+<p>Because <tt>git-cherry</tt> compares the changeset rather than the commit id
+(sha1), you can use <tt>git-cherry</tt> to find out if a commit you made locally
 has been applied &lt;upstream&gt; under a different commit id.  For example,
 this will happen if you're feeding patches &lt;upstream&gt; via email rather
 than pushing or pulling commits directly.</p>
@@ -362,7 +362,7 @@ than pushing or pulling commits directly.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:25 UTC
+Last updated 02-Jul-2008 03:01:35 UTC
 </div>
 </div>
 </body>
diff --git a/git-cherry.txt b/git-cherry.txt
index ef7caf61e..9859bc8f2 100644
--- a/git-cherry.txt
+++ b/git-cherry.txt
@@ -7,14 +7,14 @@ git-cherry - Find commits not merged upstream
 
 SYNOPSIS
 --------
-'git-cherry' [-v] <upstream> [<head>] [<limit>]
+'git cherry' [-v] <upstream> [<head>] [<limit>]
 
 DESCRIPTION
 -----------
 The changeset (or "diff") of each commit between the fork-point and <head>
 is compared against each commit between the fork-point and <upstream>.
-The commits are compared with their 'patch id', obtained from linkgit:git-patch-id[1]
-program.
+The commits are compared with their 'patch id', obtained from
+the `git-patch-id` program.
 
 Every commit that doesn't exist in the <upstream> branch
 has its id (sha1) reported, prefixed by a symbol.  The ones that have
@@ -37,8 +37,8 @@ to and including <limit> are not reported:
               \__*__*__<limit>__-__+__> <head>
 
 
-Because git-cherry compares the changeset rather than the commit id
-(sha1), you can use git-cherry to find out if a commit you made locally
+Because `git-cherry` compares the changeset rather than the commit id
+(sha1), you can use `git-cherry` to find out if a commit you made locally
 has been applied <upstream> under a different commit id.  For example,
 this will happen if you're feeding patches <upstream> via email rather
 than pushing or pulling commits directly.
diff --git a/git-citool.html b/git-citool.html
index b7c9a519e..75c82276f 100644
--- a/git-citool.html
+++ b/git-citool.html
@@ -279,8 +279,8 @@ git-citool(1) Manual Page
 <p>A Tcl/Tk based graphical interface to review modified files, stage
 them into the index, enter a commit message and record the new
 commit onto the current branch.  This interface is an alternative
-to the less interactive <a href="git-commit.html">git-commit(1)</a> program.</p>
-<p>git-citool is actually a standard alias for <em>git gui citool</em>.
+to the less interactive <tt>git-commit</tt> program.</p>
+<p><tt>git-citool</tt> is actually a standard alias for <tt>git gui citool</tt>.
 See <a href="git-gui.html">git-gui(1)</a> for more details.</p>
 </div>
 <h2>Author</h2>
@@ -297,7 +297,7 @@ See <a href="git-gui.html">git-gui(1)</a> for more details.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:25 UTC
+Last updated 02-Jul-2008 03:01:35 UTC
 </div>
 </div>
 </body>
diff --git a/git-citool.txt b/git-citool.txt
index 09108d0e6..8e6c7e67c 100644
--- a/git-citool.txt
+++ b/git-citool.txt
@@ -14,9 +14,9 @@ DESCRIPTION
 A Tcl/Tk based graphical interface to review modified files, stage
 them into the index, enter a commit message and record the new
 commit onto the current branch.  This interface is an alternative
-to the less interactive linkgit:git-commit[1] program.
+to the less interactive `git-commit` program.
 
-git-citool is actually a standard alias for 'git gui citool'.
+`git-citool` is actually a standard alias for `git gui citool`.
 See linkgit:git-gui[1] for more details.
 
 Author
diff --git a/git-clean.html b/git-clean.html
index ecf487dda..bef7d1102 100644
--- a/git-clean.html
+++ b/git-clean.html
@@ -273,7 +273,7 @@ git-clean(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-clean</em> [-d] [-f] [-n] [-q] [-x | -X] [--] &lt;paths&gt;&#8230;</div></div>
+<div class="content"><em>git clean</em> [-d] [-f] [-n] [-q] [-x | -X] [--] &lt;paths&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -301,7 +301,7 @@ affected are further limited to those that match them.</p>
 <dd>
 <p>
         If the git configuration specifies clean.requireForce as true,
-        git-clean will refuse to run unless given -f or -n.
+        <tt>git-clean</tt> will refuse to run unless given -f or -n.
 </p>
 </dd>
 <dt>
@@ -334,7 +334,7 @@ affected are further limited to those that match them.</p>
 <p>
         Don't use the ignore rules.  This allows removing all untracked
         files, including build products.  This can be used (possibly in
-        conjunction with <a href="git-reset.html">git-reset(1)</a>) to create a pristine
+        conjunction with <tt>git-reset</tt>) to create a pristine
         working directory to test a clean build.
 </p>
 </dd>
@@ -359,7 +359,7 @@ affected are further limited to those that match them.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:23 UTC
+Last updated 02-Jul-2008 03:01:36 UTC
 </div>
 </div>
 </body>
diff --git a/git-clean.txt b/git-clean.txt
index 37a82ee4b..8168bf3bf 100644
--- a/git-clean.txt
+++ b/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 --------
 [verse]
-'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
+'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
 
 DESCRIPTION
 -----------
@@ -27,7 +27,7 @@ OPTIONS
 
 -f::
 	If the git configuration specifies clean.requireForce as true,
-	git-clean will refuse to run unless given -f or -n.
+	`git-clean` will refuse to run unless given -f or -n.
 
 -n::
 --dry-run::
@@ -41,7 +41,7 @@ OPTIONS
 -x::
 	Don't use the ignore rules.  This allows removing all untracked
 	files, including build products.  This can be used (possibly in
-	conjunction with linkgit:git-reset[1]) to create a pristine
+	conjunction with `git-reset`) to create a pristine
 	working directory to test a clean build.
 
 -X::
diff --git a/git-clone.html b/git-clone.html
index e7c76397e..37bd14dcc 100644
--- a/git-clone.html
+++ b/git-clone.html
@@ -273,7 +273,7 @@ git-clone(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-clone</em> [--template=&lt;template_directory&gt;]
+<div class="content"><em>git clone</em> [--template=&lt;template_directory&gt;]
           [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
           [-o &lt;name&gt;] [-u &lt;upload-pack&gt;] [--reference &lt;repository&gt;]
           [--depth &lt;depth&gt;] [--] &lt;repository&gt; [&lt;directory&gt;]</div></div>
@@ -347,10 +347,10 @@ it unless you understand what it does. If you clone your
 repository using this option and then delete branches (or use any
 other git command that makes any existing commit unreferenced) in the
 source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as git-commit[1])
-which automatically call git-gc[1]. If these objects are removed and
-were referenced by the cloned repository, then the cloned repository
-will become corrupt.</p>
+These objects may be removed by normal git operations (such as <tt>git-commit</tt>)
+which automatically call <tt>git gc --auto</tt>. (See <a href="git-gc.html">git-gc(1)</a>.)
+If these objects are removed and were referenced by the cloned repository,
+then the cloned repository will become corrupt.</p>
 </dd>
 <dt>
 --reference &lt;repository&gt;
@@ -375,7 +375,7 @@ will become corrupt.</p>
 <dd>
 <p>
         Operate quietly.  This flag is passed to "rsync" and
-        "git-fetch-pack" commands when given.
+        <tt>git-fetch-pack</tt> commands when given.
 </p>
 </dd>
 <dt>
@@ -427,7 +427,7 @@ will become corrupt.</p>
 <dd>
 <p>
         When given, and the repository to clone from is handled
-        by <em>git-fetch-pack</em>, <em>--exec=&lt;upload-pack&gt;</em> is passed to
+        by <tt>git-fetch-pack</tt>, <tt>--exec=&lt;upload-pack&gt;</tt> is passed to
         the command to specify non-default path for the command
         run on the other end.
 </p>
@@ -668,7 +668,7 @@ Create a repository on the kernel.org machine that borrows from Linus
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:26 UTC
+Last updated 02-Jul-2008 03:01:36 UTC
 </div>
 </div>
 </body>
diff --git a/git-clone.txt b/git-clone.txt
index 7973e6af4..eef95a404 100644
--- a/git-clone.txt
+++ b/git-clone.txt
@@ -9,7 +9,7 @@ git-clone - Clone a repository into a new directory
 SYNOPSIS
 --------
 [verse]
-'git-clone' [--template=<template_directory>]
+'git clone' [--template=<template_directory>]
 	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
 	  [-o <name>] [-u <upload-pack>] [--reference <repository>]
 	  [--depth <depth>] [--] <repository> [<directory>]
@@ -68,10 +68,10 @@ it unless you understand what it does. If you clone your
 repository using this option and then delete branches (or use any
 other git command that makes any existing commit unreferenced) in the
 source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as git-commit[1])
-which automatically call git-gc[1]. If these objects are removed and
-were referenced by the cloned repository, then the cloned repository
-will become corrupt.
+These objects may be removed by normal git operations (such as `git-commit`)
+which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
+If these objects are removed and were referenced by the cloned repository,
+then the cloned repository will become corrupt.
 
 
 
@@ -88,7 +88,7 @@ will become corrupt.
 --quiet::
 -q::
 	Operate quietly.  This flag is passed to "rsync" and
-	"git-fetch-pack" commands when given.
+	`git-fetch-pack` commands when given.
 
 --no-checkout::
 -n::
@@ -114,7 +114,7 @@ will become corrupt.
 --upload-pack <upload-pack>::
 -u <upload-pack>::
 	When given, and the repository to clone from is handled
-	by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+	by `git-fetch-pack`, `--exec=<upload-pack>` is passed to
 	the command to specify non-default path for the command
 	run on the other end.
 
diff --git a/git-commit-tree.html b/git-commit-tree.html
index 2345daac1..0e5372683 100644
--- a/git-commit-tree.html
+++ b/git-commit-tree.html
@@ -272,7 +272,7 @@ git-commit-tree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-commit-tree</em> &lt;tree&gt; [-p &lt;parent commit&gt;]* &lt; changelog</p>
+<p><em>git commit-tree</em> &lt;tree&gt; [-p &lt;parent commit&gt;]* &lt; changelog</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -352,7 +352,7 @@ EMAIL</tt></pre>
 is taken from the configuration items user.name and user.email, or, if not
 present, system user name and fully qualified hostname.</p>
 <p>A commit comment is read from stdin. If a changelog
-entry is not provided via "&lt;" redirection, "git-commit-tree" will just wait
+entry is not provided via "&lt;" redirection, <tt>git-commit-tree</tt> will just wait
 for one to be entered and terminated with ^D.</p>
 </div>
 <h2>Diagnostics</h2>
@@ -477,7 +477,7 @@ reversible operation.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:27 UTC
+Last updated 02-Jul-2008 03:01:36 UTC
 </div>
 </div>
 </body>
diff --git a/git-commit-tree.txt b/git-commit-tree.txt
index 728c2fae8..9cd8d07c8 100644
--- a/git-commit-tree.txt
+++ b/git-commit-tree.txt
@@ -8,7 +8,7 @@ git-commit-tree - Create a new commit object
 
 SYNOPSIS
 --------
-'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
+'git commit-tree' <tree> [-p <parent commit>]\* < changelog
 
 DESCRIPTION
 -----------
@@ -70,7 +70,7 @@ is taken from the configuration items user.name and user.email, or, if not
 present, system user name and fully qualified hostname.
 
 A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, "git-commit-tree" will just wait
+entry is not provided via "<" redirection, `git-commit-tree` will just wait
 for one to be entered and terminated with ^D.
 
 
diff --git a/git-commit.html b/git-commit.html
index 96224bce7..696c0cbf2 100644
--- a/git-commit.html
+++ b/git-commit.html
@@ -273,7 +273,7 @@ git-commit(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-commit</em> [-a | --interactive] [-s] [-v] [-u&lt;mode&gt;] [--amend]
+<div class="content"><em>git commit</em> [-a | --interactive] [-s] [-v] [-u&lt;mode&gt;] [--amend]
            [(-c | -C) &lt;commit&gt;] [-F &lt;file&gt; | -m &lt;msg&gt;]
            [--allow-empty] [--no-verify] [-e] [--author=&lt;author&gt;]
            [--cleanup=&lt;mode&gt;] [--] [[-i | -o ]&lt;file&gt;&#8230;]</div></div>
@@ -286,14 +286,14 @@ commit along with a log message describing the changes you have made.</p>
 <ol>
 <li>
 <p>
-by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
+by using <tt>git-add</tt> to incrementally "add" changes to the
    index before using the <em>commit</em> command (Note: even modified
    files must be "added");
 </p>
 </li>
 <li>
 <p>
-by using <a href="git-rm.html">git-rm(1)</a> to remove files from the working tree
+by using <tt>git-rm</tt> to remove files from the working tree
    and the index, again before using the <em>commit</em> command;
 </p>
 </li>
@@ -321,12 +321,12 @@ by using the --interactive switch with the <em>commit</em> command to decide one
 </p>
 </li>
 </ol>
-<p>The <a href="git-status.html">git-status(1)</a> command can be used to obtain a
+<p>The <tt>git-status</tt> command can be used to obtain a
 summary of what is included by any of the above for the next
 commit by giving the same set of parameters you would give to
 this command.</p>
-<p>If you make a commit and then found a mistake immediately after
-that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>
+<p>If you make a commit and then find a mistake immediately after
+that, you can recover from it with <tt>git-reset</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -436,7 +436,7 @@ that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p
 <dd>
 <p>
         This option bypasses the pre-commit and commit-msg hooks.
-        See also <a href="githooks.html">githooks(5)</a>[hooks].
+        See also <a href="githooks.html">githooks(5)</a>.
 </p>
 </dd>
 <dt>
@@ -620,9 +620,9 @@ specified.</p>
 <div class="sectionbody">
 <p>When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
-called the "index" with <a href="git-add.html">git-add(1)</a>.  A file can be
+called the "index" with <tt>git-add</tt>.  A file can be
 reverted back, only in the index but not in the working tree,
-to that of the last commit with <tt>git-reset HEAD &#8212; &lt;file&gt;</tt>,
+to that of the last commit with <tt>git reset HEAD &#8212; &lt;file&gt;</tt>,
 which effectively reverts <tt>git-add</tt> and prevents the changes to
 this file from participating in the next commit.  After building
 the state to be committed incrementally with these commands,
@@ -673,13 +673,13 @@ sequence, if you do:</p>
 </div></div>
 <p>this second commit would record the changes to <tt>hello.c</tt> and
 <tt>hello.h</tt> as expected.</p>
-<p>After a merge (initiated by either <a href="git-merge.html">git-merge(1)</a> or
-<a href="git-pull.html">git-pull(1)</a>) stops because of conflicts, cleanly merged
+<p>After a merge (initiated by <tt>git-merge</tt> or <tt>git-pull</tt>) stops
+because of conflicts, cleanly merged
 paths are already staged to be committed for you, and paths that
 conflicted are left in unmerged state.  You would have to first
-check which paths are conflicting with <a href="git-status.html">git-status(1)</a>
+check which paths are conflicting with <tt>git-status</tt>
 and after fixing them manually in your working tree, you would
-stage the result as usual with <a href="git-add.html">git-add(1)</a>:</p>
+stage the result as usual with <tt>git-add</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git status | grep unmerged
@@ -791,7 +791,7 @@ order).</p>
 <h2>HOOKS</h2>
 <div class="sectionbody">
 <p>This command can run <tt>commit-msg</tt>, <tt>prepare-commit-msg</tt>, <tt>pre-commit</tt>,
-and <tt>post-commit</tt> hooks.  See <a href="githooks.html">githooks(5)</a>[hooks] for more
+and <tt>post-commit</tt> hooks.  See <a href="githooks.html">githooks(5)</a> for more
 information.</p>
 </div>
 <h2>SEE ALSO</h2>
@@ -813,7 +813,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:34 UTC
+Last updated 02-Jul-2008 03:01:36 UTC
 </div>
 </div>
 </body>
diff --git a/git-commit.txt b/git-commit.txt
index d0fe192fb..03594cd5d 100644
--- a/git-commit.txt
+++ b/git-commit.txt
@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
 SYNOPSIS
 --------
 [verse]
-'git-commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
+'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
 	   [(-c | -C) <commit>] [-F <file> | -m <msg>]
 	   [--allow-empty] [--no-verify] [-e] [--author=<author>]
 	   [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
@@ -20,11 +20,11 @@ commit along with a log message describing the changes you have made.
 
 The content to be added can be specified in several ways:
 
-1. by using linkgit:git-add[1] to incrementally "add" changes to the
+1. by using `git-add` to incrementally "add" changes to the
    index before using the 'commit' command (Note: even modified
    files must be "added");
 
-2. by using linkgit:git-rm[1] to remove files from the working tree
+2. by using `git-rm` to remove files from the working tree
    and the index, again before using the 'commit' command;
 
 3. by listing files as arguments to the 'commit' command, in which
@@ -41,13 +41,13 @@ The content to be added can be specified in several ways:
    by one which files should be part of the commit, before finalizing the
    operation.  Currently, this is done by invoking `git-add --interactive`.
 
-The linkgit:git-status[1] command can be used to obtain a
+The `git-status` command can be used to obtain a
 summary of what is included by any of the above for the next
 commit by giving the same set of parameters you would give to
 this command.
 
-If you make a commit and then found a mistake immediately after
-that, you can recover from it with linkgit:git-reset[1].
+If you make a commit and then find a mistake immediately after
+that, you can recover from it with `git-reset`.
 
 
 OPTIONS
@@ -97,7 +97,7 @@ OPTIONS
 -n::
 --no-verify::
 	This option bypasses the pre-commit and commit-msg hooks.
-	See also linkgit:githooks[5][hooks].
+	See also linkgit:githooks[5].
 
 --allow-empty::
 	Usually recording a commit that has the exact same tree as its
@@ -205,9 +205,9 @@ EXAMPLES
 --------
 When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
-called the "index" with linkgit:git-add[1].  A file can be
+called the "index" with `git-add`.  A file can be
 reverted back, only in the index but not in the working tree,
-to that of the last commit with `git-reset HEAD -- <file>`,
+to that of the last commit with `git reset HEAD -- <file>`,
 which effectively reverts `git-add` and prevents the changes to
 this file from participating in the next commit.  After building
 the state to be committed incrementally with these commands,
@@ -264,13 +264,13 @@ $ git commit
 this second commit would record the changes to `hello.c` and
 `hello.h` as expected.
 
-After a merge (initiated by either linkgit:git-merge[1] or
-linkgit:git-pull[1]) stops because of conflicts, cleanly merged
+After a merge (initiated by `git-merge` or `git-pull`) stops
+because of conflicts, cleanly merged
 paths are already staged to be committed for you, and paths that
 conflicted are left in unmerged state.  You would have to first
-check which paths are conflicting with linkgit:git-status[1]
+check which paths are conflicting with `git-status`
 and after fixing them manually in your working tree, you would
-stage the result as usual with linkgit:git-add[1]:
+stage the result as usual with `git-add`:
 
 ------------
 $ git status | grep unmerged
@@ -316,7 +316,7 @@ order).
 HOOKS
 -----
 This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
-and `post-commit` hooks.  See linkgit:githooks[5][hooks] for more
+and `post-commit` hooks.  See linkgit:githooks[5] for more
 information.
 
 
diff --git a/git-config.html b/git-config.html
index 8b21f4c48..d2df6d30c 100644
--- a/git-config.html
+++ b/git-config.html
@@ -273,19 +273,19 @@ git-config(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-config</em> [&lt;file-option&gt;] [type] [-z|--null] name [value [value_regex]]
-<em>git-config</em> [&lt;file-option&gt;] [type] --add name value
-<em>git-config</em> [&lt;file-option&gt;] [type] --replace-all name [value [value_regex]]
-<em>git-config</em> [&lt;file-option&gt;] [type] [-z|--null] --get name [value_regex]
-<em>git-config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-all name [value_regex]
-<em>git-config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-regexp name_regex [value_regex]
-<em>git-config</em> [&lt;file-option&gt;] --unset name [value_regex]
-<em>git-config</em> [&lt;file-option&gt;] --unset-all name [value_regex]
-<em>git-config</em> [&lt;file-option&gt;] --rename-section old_name new_name
-<em>git-config</em> [&lt;file-option&gt;] --remove-section name
-<em>git-config</em> [&lt;file-option&gt;] [-z|--null] -l | --list
-<em>git-config</em> [&lt;file-option&gt;] --get-color name [default]
-<em>git-config</em> [&lt;file-option&gt;] --get-colorbool name [stdout-is-tty]</div></div>
+<div class="content"><em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] name [value [value_regex]]
+<em>git config</em> [&lt;file-option&gt;] [type] --add name value
+<em>git config</em> [&lt;file-option&gt;] [type] --replace-all name [value [value_regex]]
+<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get name [value_regex]
+<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-all name [value_regex]
+<em>git config</em> [&lt;file-option&gt;] [type] [-z|--null] --get-regexp name_regex [value_regex]
+<em>git config</em> [&lt;file-option&gt;] --unset name [value_regex]
+<em>git config</em> [&lt;file-option&gt;] --unset-all name [value_regex]
+<em>git config</em> [&lt;file-option&gt;] --rename-section old_name new_name
+<em>git config</em> [&lt;file-option&gt;] --remove-section name
+<em>git config</em> [&lt;file-option&gt;] [-z|--null] -l | --list
+<em>git config</em> [&lt;file-option&gt;] --get-color name [default]
+<em>git config</em> [&lt;file-option&gt;] --get-colorbool name [stdout-is-tty]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -299,7 +299,7 @@ existing values that match the regexp are updated or unset.  If
 you want to handle the lines that do <strong>not</strong> match the regex, just
 prepend a single exclamation mark in front (see also <a href="#EXAMPLES">[EXAMPLES]</a>).</p>
 <p>The type specifier can be either <em>--int</em> or <em>--bool</em>, which will make
-<em>git-config</em> ensure that the variable(s) are of the given type and
+<tt>git-config</tt> ensure that the variable(s) are of the given type and
 convert the value to the canonical form (simple decimal number for int,
 a "true" or "false" string for bool).  If no type specifier is passed,
 no checks or transformations are performed on the value.</p>
@@ -479,7 +479,7 @@ rather than from all available files.</p>
 </dt>
 <dd>
 <p>
-        git-config will ensure that the output is "true" or "false"
+        <tt>git-config</tt> will ensure that the output is "true" or "false"
 </p>
 </dd>
 <dt>
@@ -487,7 +487,7 @@ rather than from all available files.</p>
 </dt>
 <dd>
 <p>
-        git-config will ensure that the output is a simple
+        <tt>git-config</tt> will ensure that the output is a simple
         decimal number.  An optional value suffix of <em>k</em>, <em>m</em>, or <em>g</em>
         in the config file will cause the value to be multiplied
         by 1024, 1048576, or 1073741824 prior to output.
@@ -540,7 +540,7 @@ rather than from all available files.</p>
 <h2><a id="FILES"></a>FILES</h2>
 <div class="sectionbody">
 <p>If not set explicitly with <em>--file</em>, there are three files where
-git-config will search for configuration options:</p>
+<tt>git-config</tt> will search for configuration options:</p>
 <dl>
 <dt>
 $GIT_DIR/config
@@ -573,11 +573,11 @@ $(prefix)/etc/gitconfig
 <p>If no further options are given, all reading options will read all of these
 files that are available. If the global or the system-wide configuration
 file are not available they will be ignored. If the repository configuration
-file is not available or readable, git-config will exit with a non-zero
+file is not available or readable, <tt>git-config</tt> will exit with a non-zero
 error code. However, in neither case will an error message be issued.</p>
 <p>All writing options will per default write to the repository specific
 configuration file. Note that this also affects options like <em>--replace-all</em>
-and <em>--unset</em>. <strong>git-config will only ever change one file at a time</strong>.</p>
+and <em>--unset</em>. <strong><tt>git-config</tt> will only ever change one file at a time</strong>.</p>
 <p>You can override these rules either by command line options or by environment
 variables. The <em>--global</em> and the <em>--system</em> options will limit the file used
 to the global or system-wide file respectively. The GIT_CONFIG environment
@@ -2300,10 +2300,17 @@ pack.indexVersion
         legacy pack index used by Git versions prior to 1.5.2, and 2 for
         the new pack index with capabilities for packs larger than 4 GB
         as well as proper protection against the repacking of corrupted
-        packs.  Version 2 is selected and this config option ignored
-        whenever the corresponding pack is larger than 2 GB.  Otherwise
-        the default is 1.
+        packs.  Version 2 is the default.  Note that version 2 is enforced
+        and this config option ignored whenever the corresponding pack is
+        larger than 2 GB.
 </p>
+<p>If you have an old git that does not understand the version 2 <tt>&#42;.idx</tt> file,
+cloning or fetching over a non native protocol (e.g. "http" and "rsync")
+that will copy both <tt>&#42;.pack</tt> file and corresponding <tt>&#42;.idx</tt> file from the
+other side may give you a repository that cannot be accessed with your
+older version of git. If the <tt>&#42;.pack</tt> file is smaller than 2 GB, however,
+you can use <a href="git-index-pack.html">git-index-pack(1)</a> on the *.pack file to regenerate
+the <tt>&#42;.idx</tt> file.</p>
 </dd>
 <dt>
 pack.packSizeLimit
@@ -2429,8 +2436,12 @@ repack.usedeltabaseoffset
 </dt>
 <dd>
 <p>
-        Allow <a href="git-repack.html">git-repack(1)</a> to create packs that uses
-        delta-base offset.  Defaults to false.
+        By default, <a href="git-repack.html">git-repack(1)</a> creates packs that use
+        delta-base offset. If you need to share your repository with
+        git older than version 1.4.4, either directly or via a dumb
+        protocol such as http, then you need to set this option to
+        "false" and repack. Access from old git versions over the
+        native protocol are unaffected by this option.
 </p>
 </dd>
 <dt>
@@ -2629,7 +2640,7 @@ web.browser
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 29-Jun-2008 08:48:21 UTC
+Last updated 02-Jul-2008 03:01:37 UTC
 </div>
 </div>
 </body>
diff --git a/git-config.txt b/git-config.txt
index c90421ee7..63ddb2c2f 100644
--- a/git-config.txt
+++ b/git-config.txt
@@ -9,19 +9,19 @@ git-config - Get and set repository or global options
 SYNOPSIS
 --------
 [verse]
-'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
-'git-config' [<file-option>] [type] --add name value
-'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
-'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
-'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
-'git-config' [<file-option>] --unset name [value_regex]
-'git-config' [<file-option>] --unset-all name [value_regex]
-'git-config' [<file-option>] --rename-section old_name new_name
-'git-config' [<file-option>] --remove-section name
-'git-config' [<file-option>] [-z|--null] -l | --list
-'git-config' [<file-option>] --get-color name [default]
-'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
+'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
+'git config' [<file-option>] [type] --add name value
+'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
+'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
+'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
+'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
+'git config' [<file-option>] --unset name [value_regex]
+'git config' [<file-option>] --unset-all name [value_regex]
+'git config' [<file-option>] --rename-section old_name new_name
+'git config' [<file-option>] --remove-section name
+'git config' [<file-option>] [-z|--null] -l | --list
+'git config' [<file-option>] --get-color name [default]
+'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
 
 DESCRIPTION
 -----------
@@ -37,7 +37,7 @@ you want to handle the lines that do *not* match the regex, just
 prepend a single exclamation mark in front (see also <<EXAMPLES>>).
 
 The type specifier can be either '--int' or '--bool', which will make
-'git-config' ensure that the variable(s) are of the given type and
+`git-config` ensure that the variable(s) are of the given type and
 convert the value to the canonical form (simple decimal number for int,
 a "true" or "false" string for bool).  If no type specifier is passed,
 no checks or transformations are performed on the value.
@@ -122,10 +122,10 @@ See also <<FILES>>.
 	List all variables set in config file.
 
 --bool::
-	git-config will ensure that the output is "true" or "false"
+	`git-config` will ensure that the output is "true" or "false"
 
 --int::
-	git-config will ensure that the output is a simple
+	`git-config` will ensure that the output is a simple
 	decimal number.  An optional value suffix of 'k', 'm', or 'g'
 	in the config file will cause the value to be multiplied
 	by 1024, 1048576, or 1073741824 prior to output.
@@ -162,7 +162,7 @@ FILES
 -----
 
 If not set explicitly with '--file', there are three files where
-git-config will search for configuration options:
+`git-config` will search for configuration options:
 
 $GIT_DIR/config::
 	Repository specific configuration file. (The filename is
@@ -179,12 +179,12 @@ $(prefix)/etc/gitconfig::
 If no further options are given, all reading options will read all of these
 files that are available. If the global or the system-wide configuration
 file are not available they will be ignored. If the repository configuration
-file is not available or readable, git-config will exit with a non-zero
+file is not available or readable, `git-config` will exit with a non-zero
 error code. However, in neither case will an error message be issued.
 
 All writing options will per default write to the repository specific
 configuration file. Note that this also affects options like '--replace-all'
-and '--unset'. *git-config will only ever change one file at a time*.
+and '--unset'. *`git-config` will only ever change one file at a time*.
 
 You can override these rules either by command line options or by environment
 variables. The '--global' and the '--system' options will limit the file used
diff --git a/git-count-objects.html b/git-count-objects.html
index ba981a523..800b68c12 100644
--- a/git-count-objects.html
+++ b/git-count-objects.html
@@ -272,7 +272,7 @@ git-count-objects(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-count-objects</em> [-v]</p>
+<p><em>git count-objects</em> [-v]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -293,7 +293,7 @@ them, to help you decide when it is a good time to repack.</p>
         In addition to the number of loose objects and disk
         space consumed, it reports the number of in-pack
         objects, number of packs, and number of objects that can be
-        removed by running <tt>git-prune-packed</tt>.
+        removed by running <tt>git prune-packed</tt>.
 </p>
 </dd>
 </dl>
@@ -312,7 +312,7 @@ them, to help you decide when it is a good time to repack.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:27 UTC
+Last updated 02-Jul-2008 03:01:37 UTC
 </div>
 </div>
 </body>
diff --git a/git-count-objects.txt b/git-count-objects.txt
index 1ba85a259..c069cc8b0 100644
--- a/git-count-objects.txt
+++ b/git-count-objects.txt
@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
 
 SYNOPSIS
 --------
-'git-count-objects' [-v]
+'git count-objects' [-v]
 
 DESCRIPTION
 -----------
@@ -22,7 +22,7 @@ OPTIONS
 	In addition to the number of loose objects and disk
 	space consumed, it reports the number of in-pack
 	objects, number of packs, and number of objects that can be
-	removed by running `git-prune-packed`.
+	removed by running `git prune-packed`.
 
 
 Author
diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html
index 51116bcd1..054ce6240 100644
--- a/git-cvsexportcommit.html
+++ b/git-cvsexportcommit.html
@@ -272,7 +272,8 @@ git-cvsexportcommit(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-cvsexportcommit</em> [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID</p>
+<p><em>git cvsexportcommit</em> [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
+        [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -285,8 +286,8 @@ be defined. See examples below.</p>
 unchanged and up to date in the CVS checkout, and it will not autocommit
 by default.</p>
 <p>Supports file additions, removals, and commits that affect binary files.</p>
-<p>If the commit is a merge commit, you must tell git-cvsexportcommit what parent
-should the changeset be done against.</p>
+<p>If the commit is a merge commit, you must tell <tt>git-cvsexportcommit</tt> what
+parent the changeset should be done against.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -416,7 +417,7 @@ Merge one patch into CVS
 <div class="content">
 <pre><tt>$ export GIT_DIR=~/project/.git
 $ cd ~/project_cvs_checkout
-$ git-cvsexportcommit -v &lt;commit-sha1&gt;
+$ git cvsexportcommit -v &lt;commit-sha1&gt;
 $ cvs commit -F .msg &lt;files&gt;</tt></pre>
 </div></div>
 </dd>
@@ -426,7 +427,7 @@ Merge one patch into CVS (-c and -w options). The working directory is within th
 <dd>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        $ git-cvsexportcommit -v -c -w ~/project_cvs_checkout &lt;commit-sha1&gt;</tt></pre>
+<pre><tt>        $ git cvsexportcommit -v -c -w ~/project_cvs_checkout &lt;commit-sha1&gt;</tt></pre>
 </div></div>
 </dd>
 <dt>
@@ -437,7 +438,7 @@ Merge pending patches into CVS automatically &#8212; only if you really know wha
 <div class="content">
 <pre><tt>$ export GIT_DIR=~/project/.git
 $ cd ~/project_cvs_checkout
-$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v</tt></pre>
+$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v</tt></pre>
 </div></div>
 </dd>
 </dl>
@@ -456,7 +457,7 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:29 UTC
+Last updated 02-Jul-2008 03:01:38 UTC
 </div>
 </div>
 </body>
diff --git a/git-cvsexportcommit.txt b/git-cvsexportcommit.txt
index 5fa91e51a..2a02ffa7c 100644
--- a/git-cvsexportcommit.txt
+++ b/git-cvsexportcommit.txt
@@ -8,7 +8,8 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
 
 SYNOPSIS
 --------
-'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
+	[-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
 
 
 DESCRIPTION
@@ -26,8 +27,8 @@ by default.
 
 Supports file additions, removals, and commits that affect binary files.
 
-If the commit is a merge commit, you must tell git-cvsexportcommit what parent
-should the changeset be done against.
+If the commit is a merge commit, you must tell `git-cvsexportcommit` what
+parent the changeset should be done against.
 
 OPTIONS
 -------
@@ -89,14 +90,14 @@ Merge one patch into CVS::
 ------------
 $ export GIT_DIR=~/project/.git
 $ cd ~/project_cvs_checkout
-$ git-cvsexportcommit -v <commit-sha1>
+$ git cvsexportcommit -v <commit-sha1>
 $ cvs commit -F .msg <files>
 ------------
 
 Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
 +
 ------------
-	$ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
+	$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
 ------------
 
 Merge pending patches into CVS automatically -- only if you really know what you are doing::
@@ -104,7 +105,7 @@ Merge pending patches into CVS automatically -- only if you really know what you
 ------------
 $ export GIT_DIR=~/project/.git
 $ cd ~/project_cvs_checkout
-$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
+$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
 ------------
 
 Author
diff --git a/git-cvsimport.html b/git-cvsimport.html
index fd430d738..2de1108e8 100644
--- a/git-cvsimport.html
+++ b/git-cvsimport.html
@@ -273,7 +273,7 @@ git-cvsimport(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-cvsimport</em> [-o &lt;branch-for-HEAD&gt;] [-h] [-v] [-d &lt;CVSROOT&gt;]
+<div class="content"><em>git cvsimport</em> [-o &lt;branch-for-HEAD&gt;] [-h] [-v] [-d &lt;CVSROOT&gt;]
               [-A &lt;author-conv-file&gt;] [-p &lt;options-for-cvsps&gt;] [-P &lt;file&gt;]
               [-C &lt;git_repository&gt;] [-z &lt;fuzz&gt;] [-i] [-k] [-u] [-s &lt;subst&gt;]
               [-a] [-m] [-M &lt;regex&gt;] [-S &lt;regex&gt;] [-L &lt;commitlimit&gt;]
@@ -286,9 +286,9 @@ repository, or incrementally import into an existing one.</p>
 <p>Splitting the CVS log into patch sets is done by <em>cvsps</em>.
 At least version 2.1 is required.</p>
 <p>You should <strong>never</strong> do any work of your own on the branches that are
-created by git-cvsimport.  By default initial import will create and populate a
+created by <tt>git-cvsimport</tt>.  By default initial import will create and populate a
 "master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to <em>git merge</em> incremental imports, or
+to work with; after that, you need to <tt>git-merge</tt> incremental imports, or
 any CVS branches, yourself.  It is advisable to specify a named remote via
 -r to separate and protect the incoming branches.</p>
 </div>
@@ -310,7 +310,7 @@ any CVS branches, yourself.  It is advisable to specify a named remote via
 <p>
         The root of the CVS archive. May be local (a simple path) or remote;
         currently, only the :local:, :ext: and :pserver: access methods
-        are supported. If not given, git-cvsimport will try to read it
+        are supported. If not given, <tt>git-cvsimport</tt> will try to read it
         from <tt>CVS/Root</tt>. If no such file exists, it checks for the
         <tt>CVSROOT</tt> environment variable.
 </p>
@@ -321,7 +321,7 @@ any CVS branches, yourself.  It is advisable to specify a named remote via
 <dd>
 <p>
         The CVS module you want to import. Relative to &lt;CVSROOT&gt;.
-        If not given, git-cvsimport tries to read it from
+        If not given, <tt>git-cvsimport</tt> tries to read it from
         <tt>CVS/Repository</tt>.
 </p>
 </dd>
@@ -341,7 +341,7 @@ any CVS branches, yourself.  It is advisable to specify a named remote via
 <p>
         The git remote to import this CVS repository into.
         Moves all CVS branches into remotes/&lt;remote&gt;/&lt;branch&gt;
-        akin to the git-clone --use-separate-remote option.
+        akin to the <tt>git-clone</tt> "--use-separate-remote" option.
 </p>
 </dd>
 <dt>
@@ -353,7 +353,7 @@ any CVS branches, yourself.  It is advisable to specify a named remote via
         from CVS is imported to the <em>origin</em> branch within the git
         repository, as <em>HEAD</em> already has a special meaning for git.
         When a remote is specified the <em>HEAD</em> branch is named
-        remotes/&lt;remote&gt;/master mirroring git-clone behaviour.
+        remotes/&lt;remote&gt;/master mirroring <tt>git-clone</tt> behaviour.
         Use this option if you want to import into a different
         branch.
 </p>
@@ -487,15 +487,15 @@ the old cvs2git tool.</p>
         spawn=Simon Pawn &lt;spawn@frog-pond.org&gt;
 </tt></pre>
 </div></div>
-<p>git-cvsimport will make it appear as those authors had
+<p><tt>git-cvsimport</tt> will make it appear as those authors had
 their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
 all along.</p>
 <p>For convenience, this data is saved to <tt>$GIT_DIR/cvs-authors</tt>
 each time the <em>-A</em> option is provided and read from that same
-file each time git-cvsimport is run.</p>
+file each time <tt>git-cvsimport</tt> is run.</p>
 <p>It is not recommended to use this feature if you intend to
 export changes back to CVS again later with
-<a href="git-cvsexportcommit.html">git-cvsexportcommit(1)</a>.</p>
+<tt>git-cvsexportcommit</tt>.</p>
 </dd>
 <dt>
 -h
@@ -528,7 +528,7 @@ various participants of the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:30 UTC
+Last updated 02-Jul-2008 03:01:38 UTC
 </div>
 </div>
 </body>
diff --git a/git-cvsimport.txt b/git-cvsimport.txt
index 2f9b35f62..ed79bb8d5 100644
--- a/git-cvsimport.txt
+++ b/git-cvsimport.txt
@@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
 SYNOPSIS
 --------
 [verse]
-'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
+'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
 	      [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
 	      [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
 	      [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
@@ -25,9 +25,9 @@ Splitting the CVS log into patch sets is done by 'cvsps'.
 At least version 2.1 is required.
 
 You should *never* do any work of your own on the branches that are
-created by git-cvsimport.  By default initial import will create and populate a
+created by `git-cvsimport`.  By default initial import will create and populate a
 "master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to 'git merge' incremental imports, or
+to work with; after that, you need to `git-merge` incremental imports, or
 any CVS branches, yourself.  It is advisable to specify a named remote via
 -r to separate and protect the incoming branches.
 
@@ -40,13 +40,13 @@ OPTIONS
 -d <CVSROOT>::
 	The root of the CVS archive. May be local (a simple path) or remote;
 	currently, only the :local:, :ext: and :pserver: access methods
-	are supported. If not given, git-cvsimport will try to read it
+	are supported. If not given, `git-cvsimport` will try to read it
 	from `CVS/Root`. If no such file exists, it checks for the
 	`CVSROOT` environment variable.
 
 <CVS_module>::
 	The CVS module you want to import. Relative to <CVSROOT>.
-	If not given, git-cvsimport tries to read it from
+	If not given, `git-cvsimport` tries to read it from
 	`CVS/Repository`.
 
 -C <target-dir>::
@@ -56,14 +56,14 @@ OPTIONS
 -r <remote>::
 	The git remote to import this CVS repository into.
 	Moves all CVS branches into remotes/<remote>/<branch>
-	akin to the git-clone --use-separate-remote option.
+	akin to the `git-clone` "--use-separate-remote" option.
 
 -o <branch-for-HEAD>::
 	When no remote is specified (via -r) the 'HEAD' branch
 	from CVS is imported to the 'origin' branch within the git
 	repository, as 'HEAD' already has a special meaning for git.
 	When a remote is specified the 'HEAD' branch is named
-	remotes/<remote>/master mirroring git-clone behaviour.
+	remotes/<remote>/master mirroring `git-clone` behaviour.
 	Use this option if you want to import into a different
 	branch.
 +
@@ -136,17 +136,17 @@ This option can be used several times to provide several detection regexes.
 
 ---------
 +
-git-cvsimport will make it appear as those authors had
+`git-cvsimport` will make it appear as those authors had
 their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
 all along.
 +
 For convenience, this data is saved to `$GIT_DIR/cvs-authors`
 each time the '-A' option is provided and read from that same
-file each time git-cvsimport is run.
+file each time `git-cvsimport` is run.
 +
 It is not recommended to use this feature if you intend to
 export changes back to CVS again later with
-linkgit:git-cvsexportcommit[1].
+`git-cvsexportcommit`.
 
 -h::
 	Print a short usage message and exit.
diff --git a/git-cvsserver.html b/git-cvsserver.html
index d42dc0759..51269ed60 100644
--- a/git-cvsserver.html
+++ b/git-cvsserver.html
@@ -281,7 +281,7 @@ git-cvsserver(1) Manual Page
 <div class="content">cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver</div></div>
 <p>Usage:</p>
 <div class="verseblock">
-<div class="content"><em>git-cvsserver</em> [options] [pserver|server] [&lt;directory&gt; &#8230;]</div></div>
+<div class="content"><em>git cvsserver</em> [options] [pserver|server] [&lt;directory&gt; &#8230;]</div></div>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -366,7 +366,7 @@ plugin. Most functionality works fine with both of these clients.</p>
 <p>Currently cvsserver works over SSH connections for read/write clients, and
 over pserver for anonymous CVS access.</p>
 <p>CVS clients cannot tag, branch or perform GIT merges.</p>
-<p>git-cvsserver maps GIT branches to CVS modules. This is very different
+<p><tt>git-cvsserver</tt> maps GIT branches to CVS modules. This is very different
 from what most CVS users would expect since in CVS modules usually represent
 one or more directories.</p>
 </div>
@@ -394,7 +394,7 @@ looks like</p>
 </div></div>
 <p>No special setup is needed for SSH access, other than having GIT tools
 in the PATH. If you have clients that do not accept the CVS_SERVER
-environment variable, you can rename git-cvsserver to cvs.</p>
+environment variable, you can rename <tt>git-cvsserver</tt> to <tt>cvs</tt>.</p>
 <p>Note: Newer CVS versions (&gt;= 1.12.11) also support specifying
 CVS_SERVER directly in CVSROOT like</p>
 <div class="listingblock">
@@ -403,9 +403,9 @@ CVS_SERVER directly in CVSROOT like</p>
 </div></div>
 <p>This has the advantage that it will be saved in your <em>CVS/Root</em> files and
 you don't need to worry about always setting the correct environment
-variable.  SSH users restricted to git-shell don't need to override the default
-with CVS_SERVER (and shouldn't) as git-shell understands <tt>cvs</tt> to mean
-git-cvsserver and pretends that the other end runs the real cvs better.</p>
+variable.  SSH users restricted to <tt>git-shell</tt> don't need to override the default
+with CVS_SERVER (and shouldn't) as <tt>git-shell</tt> understands <tt>cvs</tt> to mean
+<tt>git-cvsserver</tt> and pretends that the other end runs the real <tt>cvs</tt> better.</p>
 </li>
 <li>
 <p>
@@ -420,7 +420,7 @@ For each repo that you want accessible from CVS you need to edit config in
         logfile=/path/to/logfile
 </tt></pre>
 </div></div>
-<p>Note: you need to ensure each user that is going to invoke git-cvsserver has
+<p>Note: you need to ensure each user that is going to invoke <tt>git-cvsserver</tt> has
 write access to the log file and to the database (see
 <a href="#dbbackend">Database Backend</a>. If you want to offer write access over
 SSH, the users of course also need write access to the git repository itself.</p>
@@ -443,7 +443,7 @@ If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
    automatically saving it in your <em>CVS/Root</em> files, then you need to set them
    explicitly in your environment.  CVSROOT should be set as per normal, but the
    directory should point at the appropriate git repo.  As above, for SSH clients
-   _not_ restricted to git-shell, CVS_SERVER should be set to git-cvsserver.
+   _not_ restricted to <tt>git-shell</tt>, CVS_SERVER should be set to <tt>git-cvsserver</tt>.
 </p>
 <div class="listingblock">
 <div class="content">
@@ -477,29 +477,29 @@ Clients should now be able to check out the project. Use the CVS <em>module</em>
 </div>
 <h2><a id="dbbackend"></a>Database Backend</h2>
 <div class="sectionbody">
-<p>git-cvsserver uses one database per git head (i.e. CVS module) to
+<p><tt>git-cvsserver</tt> uses one database per git head (i.e. CVS module) to
 store information about the repository for faster access. The
 database doesn't contain any persistent data and can be completely
 regenerated from the git repository at any time. The database
 needs to be updated (i.e. written to) after every commit.</p>
-<p>If the commit is done directly by using git (as opposed to
-using git-cvsserver) the update will need to happen on the
-next repository access by git-cvsserver, independent of
+<p>If the commit is done directly by using <tt>git</tt> (as opposed to
+using <tt>git-cvsserver</tt>) the update will need to happen on the
+next repository access by <tt>git-cvsserver</tt>, independent of
 access method and requested operation.</p>
 <p>That means that even if you offer only read access (e.g. by using
-the pserver method), git-cvsserver should have write access to
+the pserver method), <tt>git-cvsserver</tt> should have write access to
 the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time git-cvsserver is executed).</p>
+that the database is up-to-date any time <tt>git-cvsserver</tt> is executed).</p>
 <p>By default it uses SQLite databases in the git directory, named
 <tt>gitcvs.&lt;module_name&gt;.sqlite</tt>. Note that the SQLite backend creates
 temporary files in the same directory as the database file on
 write so it might not be enough to grant the users using
-git-cvsserver write access to the database file without granting
+<tt>git-cvsserver</tt> write access to the database file without granting
 them write access to the directory, too.</p>
 <p>You can configure the database backend with the following
 configuration variables:</p>
 <h3>Configuring database backend</h3>
-<p>git-cvsserver uses the Perl DBI module. Please also read
+<p><tt>git-cvsserver</tt> uses the Perl DBI module. Please also read
 its documentation if changing these variables, especially
 about <tt>DBI-&gt;connect()</tt>.</p>
 <dl>
@@ -603,7 +603,7 @@ gitcvs.dbTableNamePrefix
 </dt>
 <dd>
 <p>
-        Name of the user running git-cvsserver.
+        Name of the user running <tt>git-cvsserver</tt>.
         If no name can be determined, the
         numeric uid is used.
 </p>
@@ -642,12 +642,12 @@ Pick <em>HEAD</em> when it asks what branch/tag to check out. Untick the
 <p>Protocol notes: If you are using anonymous access via pserver, just select that.
 Those using SSH access should choose the <em>ext</em> protocol, and configure <em>ext</em>
 access on the Preferences-&gt;Team-&gt;CVS-&gt;ExtConnection pane. Set CVS_SERVER to
-<em>git-cvsserver</em>. Note that password support is not good when using <em>ext</em>,
+<tt>git-cvsserver</tt>. Note that password support is not good when using <em>ext</em>,
 you will definitely want to have SSH keys setup.</p>
 <p>Alternatively, you can just use the non-standard extssh protocol that Eclipse
 offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your <tt>.bashrc</tt>
-so that calling <em>cvs</em> effectively calls git-cvsserver.</p>
+the cvs utility on the server with <tt>git-cvsserver</tt> or manipulate your <tt>.bashrc</tt>
+so that calling <em>cvs</em> effectively calls <tt>git-cvsserver</tt>.</p>
 </div>
 <h2>Clients known to work</h2>
 <div class="sectionbody">
@@ -699,13 +699,13 @@ specified will default to <em>-kb</em> mode. Otherwise the <em>-k</em> mode
 is left blank. But if <tt>gitcvs.allbinary</tt> is set to "guess", then
 the correct <em>-k</em> mode will be guessed based on the contents of
 the file.</p>
-<p>For best consistency with cvs, it is probably best to override the
+<p>For best consistency with <tt>cvs</tt>, it is probably best to override the
 defaults by setting <tt>gitcvs.usecrlfattr</tt> to true,
 and <tt>gitcvs.allbinary</tt> to "guess".</p>
 </div>
 <h2>Dependencies</h2>
 <div class="sectionbody">
-<p>git-cvsserver depends on DBD::SQLite.</p>
+<p><tt>git-cvsserver</tt> depends on DBD::SQLite.</p>
 </div>
 <h2>Copyright and Authors</h2>
 <div class="sectionbody">
@@ -735,7 +735,7 @@ Martin Langhoff &lt;martin@catalyst.net.nz&gt;
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:28 UTC
+Last updated 02-Jul-2008 03:01:39 UTC
 </div>
 </div>
 </body>
diff --git a/git-cvsserver.txt b/git-cvsserver.txt
index 3310ae25f..e0e35dbbb 100644
--- a/git-cvsserver.txt
+++ b/git-cvsserver.txt
@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
 Usage:
 
 [verse]
-'git-cvsserver' [options] [pserver|server] [<directory> ...]
+'git cvsserver' [options] [pserver|server] [<directory> ...]
 
 OPTIONS
 -------
@@ -77,7 +77,7 @@ over pserver for anonymous CVS access.
 
 CVS clients cannot tag, branch or perform GIT merges.
 
-git-cvsserver maps GIT branches to CVS modules. This is very different
+`git-cvsserver` maps GIT branches to CVS modules. This is very different
 from what most CVS users would expect since in CVS modules usually represent
 one or more directories.
 
@@ -103,7 +103,7 @@ looks like
 ------
 No special setup is needed for SSH access, other than having GIT tools
 in the PATH. If you have clients that do not accept the CVS_SERVER
-environment variable, you can rename git-cvsserver to cvs.
+environment variable, you can rename `git-cvsserver` to `cvs`.
 
 Note: Newer CVS versions (>= 1.12.11) also support specifying
 CVS_SERVER directly in CVSROOT like
@@ -113,9 +113,9 @@ cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
 ------
 This has the advantage that it will be saved in your 'CVS/Root' files and
 you don't need to worry about always setting the correct environment
-variable.  SSH users restricted to git-shell don't need to override the default
-with CVS_SERVER (and shouldn't) as git-shell understands `cvs` to mean
-git-cvsserver and pretends that the other end runs the real cvs better.
+variable.  SSH users restricted to `git-shell` don't need to override the default
+with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
+`git-cvsserver` and pretends that the other end runs the real `cvs` better.
 --
 2. For each repo that you want accessible from CVS you need to edit config in
    the repo and add the following section.
@@ -128,7 +128,7 @@ git-cvsserver and pretends that the other end runs the real cvs better.
         logfile=/path/to/logfile
 
 ------
-Note: you need to ensure each user that is going to invoke git-cvsserver has
+Note: you need to ensure each user that is going to invoke `git-cvsserver` has
 write access to the log file and to the database (see
 <<dbbackend,Database Backend>>. If you want to offer write access over
 SSH, the users of course also need write access to the git repository itself.
@@ -150,7 +150,7 @@ allowing access over SSH.
    automatically saving it in your 'CVS/Root' files, then you need to set them
    explicitly in your environment.  CVSROOT should be set as per normal, but the
    directory should point at the appropriate git repo.  As above, for SSH clients
-   _not_ restricted to git-shell, CVS_SERVER should be set to git-cvsserver.
+   _not_ restricted to `git-shell`, CVS_SERVER should be set to `git-cvsserver`.
 +
 --
 ------
@@ -178,27 +178,27 @@ allowing access over SSH.
 Database Backend
 ----------------
 
-git-cvsserver uses one database per git head (i.e. CVS module) to
+`git-cvsserver` uses one database per git head (i.e. CVS module) to
 store information about the repository for faster access. The
 database doesn't contain any persistent data and can be completely
 regenerated from the git repository at any time. The database
 needs to be updated (i.e. written to) after every commit.
 
-If the commit is done directly by using git (as opposed to
-using git-cvsserver) the update will need to happen on the
-next repository access by git-cvsserver, independent of
+If the commit is done directly by using `git` (as opposed to
+using `git-cvsserver`) the update will need to happen on the
+next repository access by `git-cvsserver`, independent of
 access method and requested operation.
 
 That means that even if you offer only read access (e.g. by using
-the pserver method), git-cvsserver should have write access to
+the pserver method), `git-cvsserver` should have write access to
 the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time git-cvsserver is executed).
+that the database is up-to-date any time `git-cvsserver` is executed).
 
 By default it uses SQLite databases in the git directory, named
 `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
 temporary files in the same directory as the database file on
 write so it might not be enough to grant the users using
-git-cvsserver write access to the database file without granting
+`git-cvsserver` write access to the database file without granting
 them write access to the directory, too.
 
 You can configure the database backend with the following
@@ -207,7 +207,7 @@ configuration variables:
 Configuring database backend
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-git-cvsserver uses the Perl DBI module. Please also read
+`git-cvsserver` uses the Perl DBI module. Please also read
 its documentation if changing these variables, especially
 about `DBI->connect()`.
 
@@ -259,7 +259,7 @@ In `dbdriver` and `dbuser` you can use the following variables:
 %a::
 	access method (one of "ext" or "pserver")
 %u::
-	Name of the user running git-cvsserver.
+	Name of the user running `git-cvsserver`.
 	If no name can be determined, the
 	numeric uid is used.
 
@@ -280,13 +280,13 @@ To get a checkout with the Eclipse CVS client:
 Protocol notes: If you are using anonymous access via pserver, just select that.
 Those using SSH access should choose the 'ext' protocol, and configure 'ext'
 access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-'git-cvsserver'. Note that password support is not good when using 'ext',
+`git-cvsserver`. Note that password support is not good when using 'ext',
 you will definitely want to have SSH keys setup.
 
 Alternatively, you can just use the non-standard extssh protocol that Eclipse
 offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your `.bashrc`
-so that calling 'cvs' effectively calls git-cvsserver.
+the cvs utility on the server with `git-cvsserver` or manipulate your `.bashrc`
+so that calling 'cvs' effectively calls `git-cvsserver`.
 
 Clients known to work
 ---------------------
@@ -328,14 +328,13 @@ is left blank. But if `gitcvs.allbinary` is set to "guess", then
 the correct '-k' mode will be guessed based on the contents of
 the file.
 
-For best consistency with cvs, it is probably best to override the
+For best consistency with `cvs`, it is probably best to override the
 defaults by setting `gitcvs.usecrlfattr` to true,
 and `gitcvs.allbinary` to "guess".
 
 Dependencies
 ------------
-
-git-cvsserver depends on DBD::SQLite.
+`git-cvsserver` depends on DBD::SQLite.
 
 Copyright and Authors
 ---------------------
diff --git a/git-daemon.html b/git-daemon.html
index 0270c7372..dd8450564 100644
--- a/git-daemon.html
+++ b/git-daemon.html
@@ -273,7 +273,7 @@ git-daemon(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-daemon</em> [--verbose] [--syslog] [--export-all]
+<div class="content"><em>git daemon</em> [--verbose] [--syslog] [--export-all]
              [--timeout=n] [--init-timeout=n] [--strict-paths]
              [--base-path=path] [--user-path | --user-path=path]
              [--interpolated-path=pathtemplate]
@@ -291,7 +291,7 @@ that service if it is enabled.</p>
 <p>It verifies that the directory has the magic file "git-daemon-export-ok", and
 it will refuse to export any git directory that hasn't explicitly been marked
 for export this way (unless the <em>--export-all</em> parameter is specified). If you
-pass some directory paths as <em>git-daemon</em> arguments, you can further restrict
+pass some directory paths as <tt>git-daemon</tt> arguments, you can further restrict
 the offers to a whitelist comprising of those.</p>
 <p>By default, only <tt>upload-pack</tt> service is enabled, which serves
 <tt>git-fetch-pack</tt> and <tt>git-ls-remote</tt> clients, which are invoked
@@ -310,7 +310,7 @@ git repositories.</p>
 <p>
         Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
         "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
-        git-daemon will refuse to start when this option is enabled and no
+        <tt>git-daemon</tt> will refuse to start when this option is enabled and no
         whitelist is specified.
 </p>
 </dd>
@@ -320,7 +320,7 @@ git repositories.</p>
 <dd>
 <p>
         Remap all the path requests as relative to the given path.
-        This is sort of "GIT root" - if you run git-daemon with
+        This is sort of "GIT root" - if you run <tt>git-daemon</tt> with
         <em>--base-path=/srv/git</em> on example.com, then if you later try to pull
         <em>git://example.com/hello.git</em>, <tt>git-daemon</tt> will interpret the path
         as <em>/srv/git/hello.git</em>.
@@ -591,7 +591,7 @@ git             9418/tcp                # Git Version Control System</tt></pre>
 </div></div>
 </dd>
 <dt>
-git-daemon as inetd server
+<tt>git-daemon</tt> as inetd server
 </dt>
 <dd>
 <p>
@@ -602,13 +602,13 @@ git-daemon as inetd server
 </p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        git stream tcp nowait nobody  /usr/bin/git-daemon
-                git-daemon --inetd --verbose --export-all
+<pre><tt>        git stream tcp nowait nobody  /usr/bin/git
+                git daemon --inetd --verbose --export-all
                 /pub/foo /pub/bar</tt></pre>
 </div></div>
 </dd>
 <dt>
-git-daemon as inetd server for virtual hosts
+<tt>git-daemon</tt> as inetd server for virtual hosts
 </dt>
 <dd>
 <p>
@@ -619,8 +619,8 @@ git-daemon as inetd server for virtual hosts
 </p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        git stream tcp nowait nobody /usr/bin/git-daemon
-                git-daemon --inetd --verbose --export-all
+<pre><tt>        git stream tcp nowait nobody /usr/bin/git
+                git daemon --inetd --verbose --export-all
                 --interpolated-path=/pub/%H%D
                 /pub/www.example.org/software
                 /pub/www.example.com/software
@@ -634,7 +634,7 @@ clients, a symlink from <tt>/software</tt> into the appropriate
 default repository could be made as well.</p>
 </dd>
 <dt>
-git-daemon as regular daemon for virtual hosts
+<tt>git-daemon</tt> as regular daemon for virtual hosts
 </dt>
 <dd>
 <p>
@@ -644,7 +644,7 @@ git-daemon as regular daemon for virtual hosts
 </p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        git-daemon --verbose --export-all
+<pre><tt>        git daemon --verbose --export-all
                 --interpolated-path=/pub/%IP/%D
                 /pub/192.168.1.200/software
                 /pub/10.10.220.23/software</tt></pre>
@@ -688,7 +688,7 @@ selectively enable/disable services per repository
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:31 UTC
+Last updated 02-Jul-2008 03:01:39 UTC
 </div>
 </div>
 </body>
diff --git a/git-daemon.txt b/git-daemon.txt
index 344f24ea5..3cf2d3b3d 100644
--- a/git-daemon.txt
+++ b/git-daemon.txt
@@ -8,12 +8,12 @@ git-daemon - A really simple server for git repositories
 SYNOPSIS
 --------
 [verse]
-'git-daemon' [--verbose] [--syslog] [--export-all]
-             [--timeout=n] [--init-timeout=n] [--strict-paths]
-             [--base-path=path] [--user-path | --user-path=path]
-             [--interpolated-path=pathtemplate]
-             [--reuseaddr] [--detach] [--pid-file=file]
-             [--enable=service] [--disable=service]
+'git daemon' [--verbose] [--syslog] [--export-all]
+	     [--timeout=n] [--init-timeout=n] [--strict-paths]
+	     [--base-path=path] [--user-path | --user-path=path]
+	     [--interpolated-path=pathtemplate]
+	     [--reuseaddr] [--detach] [--pid-file=file]
+	     [--enable=service] [--disable=service]
 	     [--allow-override=service] [--forbid-override=service]
 	     [--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]
 	     [directory...]
@@ -27,7 +27,7 @@ that service if it is enabled.
 It verifies that the directory has the magic file "git-daemon-export-ok", and
 it will refuse to export any git directory that hasn't explicitly been marked
 for export this way (unless the '--export-all' parameter is specified). If you
-pass some directory paths as 'git-daemon' arguments, you can further restrict
+pass some directory paths as `git-daemon` arguments, you can further restrict
 the offers to a whitelist comprising of those.
 
 By default, only `upload-pack` service is enabled, which serves
@@ -44,12 +44,12 @@ OPTIONS
 --strict-paths::
 	Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
 	"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
-	git-daemon will refuse to start when this option is enabled and no
+	`git-daemon` will refuse to start when this option is enabled and no
 	whitelist is specified.
 
 --base-path::
 	Remap all the path requests as relative to the given path.
-	This is sort of "GIT root" - if you run git-daemon with
+	This is sort of "GIT root" - if you run `git-daemon` with
 	'--base-path=/srv/git' on example.com, then if you later try to pull
 	'git://example.com/hello.git', `git-daemon` will interpret the path
 	as '/srv/git/hello.git'.
@@ -199,28 +199,28 @@ $ grep 9418 /etc/services
 git		9418/tcp		# Git Version Control System
 ------------
 
-git-daemon as inetd server::
+`git-daemon` as inetd server::
 	To set up `git-daemon` as an inetd service that handles any
 	repository under the whitelisted set of directories, /pub/foo
 	and /pub/bar, place an entry like the following into
 	/etc/inetd all on one line:
 +
 ------------------------------------------------
-	git stream tcp nowait nobody  /usr/bin/git-daemon
-		git-daemon --inetd --verbose --export-all
+	git stream tcp nowait nobody  /usr/bin/git
+		git daemon --inetd --verbose --export-all
 		/pub/foo /pub/bar
 ------------------------------------------------
 
 
-git-daemon as inetd server for virtual hosts::
+`git-daemon` as inetd server for virtual hosts::
 	To set up `git-daemon` as an inetd service that handles
 	repositories for different virtual hosts, `www.example.com`
 	and `www.example.org`, place an entry like the following into
 	`/etc/inetd` all on one line:
 +
 ------------------------------------------------
-	git stream tcp nowait nobody /usr/bin/git-daemon
-		git-daemon --inetd --verbose --export-all
+	git stream tcp nowait nobody /usr/bin/git
+		git daemon --inetd --verbose --export-all
 		--interpolated-path=/pub/%H%D
 		/pub/www.example.org/software
 		/pub/www.example.com/software
@@ -235,13 +235,13 @@ clients, a symlink from `/software` into the appropriate
 default repository could be made as well.
 
 
-git-daemon as regular daemon for virtual hosts::
+`git-daemon` as regular daemon for virtual hosts::
 	To set up `git-daemon` as a regular, non-inetd service that
 	handles repositories for multiple virtual hosts based on
 	their IP addresses, start the daemon like this:
 +
 ------------------------------------------------
-	git-daemon --verbose --export-all
+	git daemon --verbose --export-all
 		--interpolated-path=/pub/%IP/%D
 		/pub/192.168.1.200/software
 		/pub/10.10.220.23/software
diff --git a/git-describe.html b/git-describe.html
index 751808168..d5b85a72b 100644
--- a/git-describe.html
+++ b/git-describe.html
@@ -272,7 +272,7 @@ git-describe(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-describe</em> [--all] [--tags] [--contains] [--abbrev=&lt;n&gt;] &lt;committish&gt;&#8230;</p>
+<p><em>git describe</em> [--all] [--tags] [--contains] [--abbrev=&lt;n&gt;] &lt;committish&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -399,7 +399,7 @@ abbreviated object name of the most recent commit.</p>
 <p>With something like git.git current tree, I get:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>[torvalds@g5 git]$ git-describe parent
+<pre><tt>[torvalds@g5 git]$ git describe parent
 v1.0.4-14-g2414721</tt></pre>
 </div></div>
 <p>i.e. the current head of my "parent" branch is based on v1.0.4,
@@ -411,10 +411,10 @@ at the end.</p>
 of commits which would be displayed by "git log v1.0.4..parent".
 The hash suffix is "-g" + 7-char abbreviation for the tip commit
 of parent (which was <tt>2414721b194453f058079d897d13c4e377f92dc6</tt>).</p>
-<p>Doing a "git-describe" on a tag-name will just show the tag name:</p>
+<p>Doing a <tt>git-describe</tt> on a tag-name will just show the tag name:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>[torvalds@g5 git]$ git-describe v1.0.4
+<pre><tt>[torvalds@g5 git]$ git describe v1.0.4
 v1.0.4</tt></pre>
 </div></div>
 <p>With --all, the command can use branch heads as references, so
@@ -439,19 +439,19 @@ tags/v1.0.0</tt></pre>
 </div>
 <h2>SEARCH STRATEGY</h2>
 <div class="sectionbody">
-<p>For each committish supplied "git describe" will first look for
+<p>For each committish supplied, <tt>git-describe</tt> will first look for
 a tag which tags exactly that commit.  Annotated tags will always
 be preferred over lightweight tags, and tags with newer dates will
 always be preferred over tags with older dates.  If an exact match
 is found, its name will be output and searching will stop.</p>
-<p>If an exact match was not found "git describe" will walk back
+<p>If an exact match was not found, <tt>git-describe</tt> will walk back
 through the commit history to locate an ancestor commit which
 has been tagged.  The ancestor's tag will be output along with an
 abbreviation of the input committish's SHA1.</p>
 <p>If multiple tags were found during the walk then the tag which
 has the fewest commits different from the input committish will be
 selected and output.  Here fewest commits different is defined as
-the number of commits which would be shown by "git log tag..input"
+the number of commits which would be shown by <tt>git log tag..input</tt>
 will be the smallest number of commits possible.</p>
 </div>
 <h2>Author</h2>
@@ -470,7 +470,7 @@ updated by Shawn Pearce &lt;spearce@spearce.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:32 UTC
+Last updated 02-Jul-2008 03:01:40 UTC
 </div>
 </div>
 </body>
diff --git a/git-describe.txt b/git-describe.txt
index 9f6f48318..51a0cc044 100644
--- a/git-describe.txt
+++ b/git-describe.txt
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
 
 SYNOPSIS
 --------
-'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
 
 DESCRIPTION
 -----------
@@ -78,7 +78,7 @@ EXAMPLES
 
 With something like git.git current tree, I get:
 
-	[torvalds@g5 git]$ git-describe parent
+	[torvalds@g5 git]$ git describe parent
 	v1.0.4-14-g2414721
 
 i.e. the current head of my "parent" branch is based on v1.0.4,
@@ -92,9 +92,9 @@ of commits which would be displayed by "git log v1.0.4..parent".
 The hash suffix is "-g" + 7-char abbreviation for the tip commit
 of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
 
-Doing a "git-describe" on a tag-name will just show the tag name:
+Doing a `git-describe` on a tag-name will just show the tag name:
 
-	[torvalds@g5 git]$ git-describe v1.0.4
+	[torvalds@g5 git]$ git describe v1.0.4
 	v1.0.4
 
 With --all, the command can use branch heads as references, so
@@ -115,13 +115,13 @@ closest tagname without any suffix:
 SEARCH STRATEGY
 ---------------
 
-For each committish supplied "git describe" will first look for
+For each committish supplied, `git-describe` will first look for
 a tag which tags exactly that commit.  Annotated tags will always
 be preferred over lightweight tags, and tags with newer dates will
 always be preferred over tags with older dates.  If an exact match
 is found, its name will be output and searching will stop.
 
-If an exact match was not found "git describe" will walk back
+If an exact match was not found, `git-describe` will walk back
 through the commit history to locate an ancestor commit which
 has been tagged.  The ancestor's tag will be output along with an
 abbreviation of the input committish's SHA1.
@@ -129,7 +129,7 @@ abbreviation of the input committish's SHA1.
 If multiple tags were found during the walk then the tag which
 has the fewest commits different from the input committish will be
 selected and output.  Here fewest commits different is defined as
-the number of commits which would be shown by "git log tag..input"
+the number of commits which would be shown by `git log tag..input`
 will be the smallest number of commits possible.
 
 
diff --git a/git-diff-files.html b/git-diff-files.html
index 4b0792b86..993785da0 100644
--- a/git-diff-files.html
+++ b/git-diff-files.html
@@ -272,14 +272,14 @@ git-diff-files(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-diff-files</em> [-q] [-0|-1|-2|-3|-c|--cc] [&lt;common diff options&gt;] [&lt;path&gt;&#8230;]</p>
+<p><em>git diff-files</em> [-q] [-0|-1|-2|-3|-c|--cc] [&lt;common diff options&gt;] [&lt;path&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Compares the files in the working tree and the index.  When paths
 are specified, compares only those named paths.  Otherwise all
 entries in the index are compared.  The output format is the
-same as "git-diff-index" and "git-diff-tree".</p>
+same as for <tt>git-diff-index</tt> and <tt>git-diff-tree</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -757,7 +757,7 @@ same as "git-diff-index" and "git-diff-tree".</p>
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 -1 -2 -3 or --base --ours --theirs, and -0
@@ -1291,7 +1291,7 @@ the pathname, but if that is <tt>NUL</tt>, the record will show two paths.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:33 UTC
+Last updated 02-Jul-2008 03:01:40 UTC
 </div>
 </div>
 </body>
diff --git a/git-diff-files.txt b/git-diff-files.txt
index 8a64869d2..6c65757ea 100644
--- a/git-diff-files.txt
+++ b/git-diff-files.txt
@@ -8,14 +8,14 @@ git-diff-files - Compares files in the working tree and the index
 
 SYNOPSIS
 --------
-'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
+'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
 
 DESCRIPTION
 -----------
 Compares the files in the working tree and the index.  When paths
 are specified, compares only those named paths.  Otherwise all
 entries in the index are compared.  The output format is the
-same as "git-diff-index" and "git-diff-tree".
+same as for `git-diff-index` and `git-diff-tree`.
 
 OPTIONS
 -------
diff --git a/git-diff-index.html b/git-diff-index.html
index 01b0b66e0..7ca898202 100644
--- a/git-diff-index.html
+++ b/git-diff-index.html
@@ -272,7 +272,7 @@ git-diff-index(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-diff-index</em> [-m] [--cached] [&lt;common diff options&gt;] &lt;tree-ish&gt; [&lt;path&gt;&#8230;]</p>
+<p><em>git diff-index</em> [-m] [--cached] [&lt;common diff options&gt;] &lt;tree-ish&gt; [&lt;path&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -758,7 +758,7 @@ entries in the index are compared.</p>
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 &lt;tree-ish&gt;
@@ -783,7 +783,7 @@ entries in the index are compared.</p>
 <p>
         By default, files recorded in the index but not checked
         out are reported as deleted.  This flag makes
-        "git-diff-index" say that all non-checked-out files are up
+        <tt>git-diff-index</tt> say that all non-checked-out files are up
         to date.
 </p>
 </dd>
@@ -1283,7 +1283,7 @@ of these operations are very useful indeed.</p>
 <div class="literalblock">
 <div class="content">
 <pre><tt>show me the differences between HEAD and the current index
-contents (the ones I'd write with a "git-write-tree")</tt></pre>
+contents (the ones I'd write using `git-write-tree`)</tt></pre>
 </div></div>
 <p>For example, let's say that you have worked on your working directory, updated
 some files in the index and are ready to commit. You want to see exactly
@@ -1291,23 +1291,23 @@ some files in the index and are ready to commit. You want to see exactly
 object and compare it that way, and to do that, you just do</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-diff-index --cached HEAD</tt></pre>
+<pre><tt>git diff-index --cached HEAD</tt></pre>
 </div></div>
 <p>Example: let's say I had renamed <tt>commit.c</tt> to <tt>git-commit.c</tt>, and I had
-done an "git-update-index" to make that effective in the index file.
-"git-diff-files" wouldn't show anything at all, since the index file
-matches my working directory. But doing a "git-diff-index" does:</p>
+done an <tt>update-index</tt> to make that effective in the index file.
+<tt>git diff-files</tt> wouldn't show anything at all, since the index file
+matches my working directory. But doing a <tt>git-diff-index</tt> does:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>torvalds@ppc970:~/git&gt; git-diff-index --cached HEAD
+<pre><tt>torvalds@ppc970:~/git&gt; git diff-index --cached HEAD
 -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
 +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c</tt></pre>
 </div></div>
 <p>You can see easily that the above is a rename.</p>
-<p>In fact, "git-diff-index --cached" <strong>should</strong> always be entirely equivalent to
-actually doing a "git-write-tree" and comparing that. Except this one is much
+<p>In fact, <tt>git diff-index --cached</tt> <strong>should</strong> always be entirely equivalent to
+actually doing a <tt>git-write-tree</tt> and comparing that. Except this one is much
 nicer for the case where you just want to check where you are.</p>
-<p>So doing a "git-diff-index --cached" is basically very useful when you are
+<p>So doing a <tt>git-diff-index --cached</tt> is basically very useful when you are
 asking yourself "what have I already marked for being committed, and
 what's the difference to a previous tree".</p>
 </div>
@@ -1315,7 +1315,7 @@ what's the difference to a previous tree".</p>
 <div class="sectionbody">
 <p>The "non-cached" mode takes a different approach, and is potentially
 the more useful of the two in that what it does can't be emulated with
-a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
+a <tt>git-write-tree</tt> + <tt>git-diff-tree</tt>. Thus that's the default mode.
 The non-cached version asks the question:</p>
 <div class="literalblock">
 <div class="content">
@@ -1323,16 +1323,16 @@ The non-cached version asks the question:</p>
 tree - index contents _and_ files that aren't up-to-date</tt></pre>
 </div></div>
 <p>which is obviously a very useful question too, since that tells you what
-you <strong>could</strong> commit. Again, the output matches the "git-diff-tree -r"
+you <strong>could</strong> commit. Again, the output matches the <tt>git-diff-tree -r</tt>
 output to a tee, but with a twist.</p>
 <p>The twist is that if some file doesn't match the index, we don't have
 a backing store thing for it, and we use the magic "all-zero" sha1 to
 show that. So let's say that you have edited <tt>kernel/sched.c</tt>, but
-have not actually done a "git-update-index" on it yet - there is no
+have not actually done a <tt>git-update-index</tt> on it yet - there is no
 "object" associated with the new state, and you get:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>torvalds@ppc970:~/v2.6/linux&gt; git-diff-index HEAD
+<pre><tt>torvalds@ppc970:~/v2.6/linux&gt; git diff-index HEAD
 *100644-&gt;100664 blob    7476bb......-&gt;000000......      kernel/sched.c</tt></pre>
 </div></div>
 <p>i.e., it shows that the tree has changed, and that <tt>kernel/sched.c</tt> has is
@@ -1344,11 +1344,11 @@ directly rather than do an object-to-object diff.</p>
 <td class="icon">
 <div class="title">Note</div>
 </td>
-<td class="content">As with other commands of this type, "git-diff-index" does not
+<td class="content">As with other commands of this type, <tt>git-diff-index</tt> does not
 actually look at the contents of the file at all. So maybe
 <tt>kernel/sched.c</tt> hasn't actually changed, and it's just that you
 touched it. In either case, it's a note that you need to
-"git-update-index" it to make the index be in sync.</td>
+<tt>git-update-index</tt> it to make the index be in sync.</td>
 </tr></table>
 </div>
 <div class="admonitionblock">
@@ -1378,7 +1378,7 @@ always have the special all-zero sha1.</td>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:34 UTC
+Last updated 02-Jul-2008 03:01:40 UTC
 </div>
 </div>
 </body>
diff --git a/git-diff-index.txt b/git-diff-index.txt
index f6e844fe6..784bbf3b0 100644
--- a/git-diff-index.txt
+++ b/git-diff-index.txt
@@ -8,7 +8,7 @@ git-diff-index - Compares content and mode of blobs between the index and reposi
 
 SYNOPSIS
 --------
-'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
+'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
 
 DESCRIPTION
 -----------
@@ -31,7 +31,7 @@ include::diff-options.txt[]
 -m::
 	By default, files recorded in the index but not checked
 	out are reported as deleted.  This flag makes
-	"git-diff-index" say that all non-checked-out files are up
+	`git-diff-index` say that all non-checked-out files are up
 	to date.
 
 Output format
@@ -50,31 +50,31 @@ Cached Mode
 If '--cached' is specified, it allows you to ask:
 
 	show me the differences between HEAD and the current index
-	contents (the ones I'd write with a "git-write-tree")
+	contents (the ones I'd write using `git-write-tree`)
 
 For example, let's say that you have worked on your working directory, updated
 some files in the index and are ready to commit. You want to see exactly
 *what* you are going to commit, without having to write a new tree
 object and compare it that way, and to do that, you just do
 
-	git-diff-index --cached HEAD
+	git diff-index --cached HEAD
 
 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
-done an "git-update-index" to make that effective in the index file.
-"git-diff-files" wouldn't show anything at all, since the index file
-matches my working directory. But doing a "git-diff-index" does:
+done an `update-index` to make that effective in the index file.
+`git diff-files` wouldn't show anything at all, since the index file
+matches my working directory. But doing a `git-diff-index` does:
 
-  torvalds@ppc970:~/git> git-diff-index --cached HEAD
+  torvalds@ppc970:~/git> git diff-index --cached HEAD
   -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
   +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c
 
 You can see easily that the above is a rename.
 
-In fact, "git-diff-index --cached" *should* always be entirely equivalent to
-actually doing a "git-write-tree" and comparing that. Except this one is much
+In fact, `git diff-index --cached` *should* always be entirely equivalent to
+actually doing a `git-write-tree` and comparing that. Except this one is much
 nicer for the case where you just want to check where you are.
 
-So doing a "git-diff-index --cached" is basically very useful when you are
+So doing a `git-diff-index --cached` is basically very useful when you are
 asking yourself "what have I already marked for being committed, and
 what's the difference to a previous tree".
 
@@ -82,23 +82,23 @@ Non-cached Mode
 ---------------
 The "non-cached" mode takes a different approach, and is potentially
 the more useful of the two in that what it does can't be emulated with
-a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
+a `git-write-tree` + `git-diff-tree`. Thus that's the default mode.
 The non-cached version asks the question:
 
   show me the differences between HEAD and the currently checked out
   tree - index contents _and_ files that aren't up-to-date
 
 which is obviously a very useful question too, since that tells you what
-you *could* commit. Again, the output matches the "git-diff-tree -r"
+you *could* commit. Again, the output matches the `git-diff-tree -r`
 output to a tee, but with a twist.
 
 The twist is that if some file doesn't match the index, we don't have
 a backing store thing for it, and we use the magic "all-zero" sha1 to
 show that. So let's say that you have edited `kernel/sched.c`, but
-have not actually done a "git-update-index" on it yet - there is no
+have not actually done a `git-update-index` on it yet - there is no
 "object" associated with the new state, and you get:
 
-  torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
+  torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
   *100644->100664 blob    7476bb......->000000......      kernel/sched.c
 
 i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
@@ -106,11 +106,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
 get the real diff, you need to look at the object in the working directory
 directly rather than do an object-to-object diff.
 
-NOTE: As with other commands of this type, "git-diff-index" does not
+NOTE: As with other commands of this type, `git-diff-index` does not
 actually look at the contents of the file at all. So maybe
 `kernel/sched.c` hasn't actually changed, and it's just that you
 touched it. In either case, it's a note that you need to
-"git-update-index" it to make the index be in sync.
+`git-update-index` it to make the index be in sync.
 
 NOTE: You can have a mixture of files show up as "has been updated"
 and "is still dirty in the working directory" together. You can always
diff --git a/git-diff-tree.html b/git-diff-tree.html
index f1875d3b3..e9b55a989 100644
--- a/git-diff-tree.html
+++ b/git-diff-tree.html
@@ -273,7 +273,7 @@ git-diff-tree(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-diff-tree</em> [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+<div class="content"><em>git diff-tree</em> [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
               [-t] [-r] [-c | --cc] [--root] [&lt;common diff options&gt;]
               &lt;tree-ish&gt; [&lt;tree-ish&gt;] [&lt;path&gt;&#8230;]</div></div>
 </div>
@@ -282,7 +282,7 @@ git-diff-tree(1) Manual Page
 <p>Compares the content and mode of the blobs found via two tree objects.</p>
 <p>If there is only one &lt;tree-ish&gt; given, the commit is compared with its parents
 (see --stdin below).</p>
-<p>Note that "git-diff-tree" can use the tree encapsulated in a commit object.</p>
+<p>Note that <tt>git-diff-tree</tt> can use the tree encapsulated in a commit object.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -760,7 +760,7 @@ git-diff-tree(1) Manual Page
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 &lt;tree-ish&gt;
@@ -827,7 +827,7 @@ separated with a single space are given.</p>
 </dt>
 <dd>
 <p>
-        By default, "git-diff-tree --stdin" does not show
+        By default, <tt>git-diff-tree --stdin</tt> does not show
         differences for merge commits.  With this flag, it shows
         differences to that commit from all of its parents. See
         also <em>-c</em>.
@@ -838,7 +838,7 @@ separated with a single space are given.</p>
 </dt>
 <dd>
 <p>
-        By default, "git-diff-tree --stdin" shows differences,
+        By default, <tt>git-diff-tree --stdin</tt> shows differences,
         either in machine-readable form (without <em>-p</em>) or in patch
         form (with <em>-p</em>).  This output can be suppressed.  It is
         only useful with <em>-v</em> flag.
@@ -849,7 +849,7 @@ separated with a single space are given.</p>
 </dt>
 <dd>
 <p>
-        This flag causes "git-diff-tree --stdin" to also show
+        This flag causes <tt>git-diff-tree --stdin</tt> to also show
         the commit message before the differences.
 </p>
 </dd>
@@ -896,7 +896,7 @@ people using 80-column terminals.</p>
 </dt>
 <dd>
 <p>
-        git-diff-tree outputs a line with the commit ID when
+        <tt>git-diff-tree</tt> outputs a line with the commit ID when
         applicable.  This flag suppressed the commit ID output.
 </p>
 </dd>
@@ -1266,13 +1266,13 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
 example some architecture-specific files, you might do:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-diff-tree -r &lt;tree-ish&gt; &lt;tree-ish&gt; arch/ia64 include/asm-ia64</tt></pre>
+<pre><tt>git diff-tree -r &lt;tree-ish&gt; &lt;tree-ish&gt; arch/ia64 include/asm-ia64</tt></pre>
 </div></div>
 <p>and it will only show you what changed in those two directories.</p>
 <p>Or if you are searching for what changed in just <tt>kernel/sched.c</tt>, just do</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-diff-tree -r &lt;tree-ish&gt; &lt;tree-ish&gt; kernel/sched.c</tt></pre>
+<pre><tt>git diff-tree -r &lt;tree-ish&gt; &lt;tree-ish&gt; kernel/sched.c</tt></pre>
 </div></div>
 <p>and it will ignore all differences to other files.</p>
 <p>The pattern is always the prefix, and is matched exactly.  There are no
@@ -1282,7 +1282,7 @@ so it can be used to name subdirectories.</p>
 <p>An example of normal usage is:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>torvalds@ppc970:~/git&gt; git-diff-tree 5319e4......
+<pre><tt>torvalds@ppc970:~/git&gt; git diff-tree 5319e4......
 *100664-&gt;100664 blob    ac348b.......-&gt;a01513.......      git-fsck-objects.c</tt></pre>
 </div></div>
 <p>which tells you that the last commit changed just one file (it's from
@@ -1797,7 +1797,7 @@ the pathname, but if that is <tt>NUL</tt>, the record will show two paths.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:41 UTC
+Last updated 02-Jul-2008 03:01:41 UTC
 </div>
 </div>
 </body>
diff --git a/git-diff-tree.txt b/git-diff-tree.txt
index 56caeb2d2..68feb0817 100644
--- a/git-diff-tree.txt
+++ b/git-diff-tree.txt
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
 SYNOPSIS
 --------
 [verse]
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
+'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
 	      [-t] [-r] [-c | --cc] [--root] [<common diff options>]
 	      <tree-ish> [<tree-ish>] [<path>...]
 
@@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
 If there is only one <tree-ish> given, the commit is compared with its parents
 (see --stdin below).
 
-Note that "git-diff-tree" can use the tree encapsulated in a commit object.
+Note that `git-diff-tree` can use the tree encapsulated in a commit object.
 
 OPTIONS
 -------
@@ -58,25 +58,25 @@ behavior.  This does not apply to the case where two <tree-ish>
 separated with a single space are given.
 
 -m::
-	By default, "git-diff-tree --stdin" does not show
+	By default, `git-diff-tree --stdin` does not show
 	differences for merge commits.  With this flag, it shows
 	differences to that commit from all of its parents. See
 	also '-c'.
 
 -s::
-	By default, "git-diff-tree --stdin" shows differences,
+	By default, `git-diff-tree --stdin` shows differences,
 	either in machine-readable form (without '-p') or in patch
 	form (with '-p').  This output can be suppressed.  It is
 	only useful with '-v' flag.
 
 -v::
-	This flag causes "git-diff-tree --stdin" to also show
+	This flag causes `git-diff-tree --stdin` to also show
 	the commit message before the differences.
 
 include::pretty-options.txt[]
 
 --no-commit-id::
-	git-diff-tree outputs a line with the commit ID when
+	`git-diff-tree` outputs a line with the commit ID when
 	applicable.  This flag suppressed the commit ID output.
 
 -c::
@@ -112,13 +112,13 @@ Limiting Output
 If you're only interested in differences in a subset of files, for
 example some architecture-specific files, you might do:
 
-	git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
+	git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
 
 and it will only show you what changed in those two directories.
 
 Or if you are searching for what changed in just `kernel/sched.c`, just do
 
-	git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
+	git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
 
 and it will ignore all differences to other files.
 
@@ -129,7 +129,7 @@ so it can be used to name subdirectories.
 
 An example of normal usage is:
 
-  torvalds@ppc970:~/git> git-diff-tree 5319e4......
+  torvalds@ppc970:~/git> git diff-tree 5319e4......
   *100664->100664 blob    ac348b.......->a01513.......      git-fsck-objects.c
 
 which tells you that the last commit changed just one file (it's from
diff --git a/git-diff.html b/git-diff.html
index e36c307a2..6ccba6cc6 100644
--- a/git-diff.html
+++ b/git-diff.html
@@ -272,7 +272,7 @@ git-diff(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-diff</em> [&lt;common diff options&gt;] &lt;commit&gt;{0,2} [--] [&lt;path&gt;&#8230;]</p>
+<p><em>git diff</em> [&lt;common diff options&gt;] &lt;commit&gt;{0,2} [--] [&lt;path&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -280,7 +280,7 @@ git-diff(1) Manual Page
 tree and the index file, or the index file and the working tree.</p>
 <dl>
 <dt>
-<em>git-diff</em> [--options] [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
@@ -295,7 +295,7 @@ compare the two files / directories. This behavior can be
 forced by --no-index.</p>
 </dd>
 <dt>
-<em>git-diff</em> [--options] --cached [&lt;commit&gt;] [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] --cached [&lt;commit&gt;] [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
@@ -306,7 +306,7 @@ forced by --no-index.</p>
 </p>
 </dd>
 <dt>
-<em>git-diff</em> [--options] &lt;commit&gt; [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] &lt;commit&gt; [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
@@ -318,7 +318,7 @@ forced by --no-index.</p>
 </p>
 </dd>
 <dt>
-<em>git-diff</em> [--options] &lt;commit&gt; &lt;commit&gt; [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] &lt;commit&gt; &lt;commit&gt; [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
@@ -327,7 +327,7 @@ forced by --no-index.</p>
 </p>
 </dd>
 <dt>
-<em>git-diff</em> [--options] &lt;commit&gt;..&lt;commit&gt; [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] &lt;commit&gt;..&lt;commit&gt; [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
@@ -337,14 +337,14 @@ forced by --no-index.</p>
 </p>
 </dd>
 <dt>
-<em>git-diff</em> [--options] &lt;commit&gt;...&lt;commit&gt; [--] [&lt;path&gt;&#8230;]
+<em>git diff</em> [--options] &lt;commit&gt;...&lt;commit&gt; [--] [&lt;path&gt;&#8230;]
 </dt>
 <dd>
 <p>
         This form is to view the changes on the branch containing
         and up to the second &lt;commit&gt;, starting at a common ancestor
-        of both &lt;commit&gt;.  "git-diff A...B" is equivalent to
-        "git-diff $(git-merge-base A B) B".  You can omit any one
+        of both &lt;commit&gt;.  "git diff A...B" is equivalent to
+        "git diff $(git-merge-base A B) B".  You can omit any one
         of &lt;commit&gt;, which has the same effect as using HEAD instead.
 </p>
 </dd>
@@ -836,7 +836,7 @@ and the range notations ("&lt;commit&gt;..&lt;commit&gt;" and
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 &lt;path&gt;&#8230;
@@ -1493,7 +1493,7 @@ Output diff in reverse.
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:36 UTC
+Last updated 02-Jul-2008 03:01:41 UTC
 </div>
 </div>
 </body>
diff --git a/git-diff.txt b/git-diff.txt
index 7acd42896..c53eba557 100644
--- a/git-diff.txt
+++ b/git-diff.txt
@@ -8,14 +8,14 @@ git-diff - Show changes between commits, commit and working tree, etc
 
 SYNOPSIS
 --------
-'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
+'git diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
 
 DESCRIPTION
 -----------
 Show changes between two trees, a tree and the working tree, a
 tree and the index file, or the index file and the working tree.
 
-'git-diff' [--options] [--] [<path>...]::
+'git diff' [--options] [--] [<path>...]::
 
 	This form is to view the changes you made relative to
 	the index (staging area for the next commit).  In other
@@ -27,14 +27,14 @@ If exactly two paths are given, and at least one is untracked,
 compare the two files / directories. This behavior can be
 forced by --no-index.
 
-'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
+'git diff' [--options] --cached [<commit>] [--] [<path>...]::
 
 	This form is to view the changes you staged for the next
 	commit relative to the named <commit>.  Typically you
 	would want comparison with the latest commit, so if you
 	do not give <commit>, it defaults to HEAD.
 
-'git-diff' [--options] <commit> [--] [<path>...]::
+'git diff' [--options] <commit> [--] [<path>...]::
 
 	This form is to view the changes you have in your
 	working tree relative to the named <commit>.  You can
@@ -42,23 +42,23 @@ forced by --no-index.
 	branch name to compare with the tip of a different
 	branch.
 
-'git-diff' [--options] <commit> <commit> [--] [<path>...]::
+'git diff' [--options] <commit> <commit> [--] [<path>...]::
 
 	This is to view the changes between two arbitrary
 	<commit>.
 
-'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
+'git diff' [--options] <commit>..<commit> [--] [<path>...]::
 
 	This is synonymous to the previous form.  If <commit> on
 	one side is omitted, it will have the same effect as
 	using HEAD instead.
 
-'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
+'git diff' [--options] <commit>\...<commit> [--] [<path>...]::
 
 	This form is to view the changes on the branch containing
 	and up to the second <commit>, starting at a common ancestor
-	of both <commit>.  "git-diff A\...B" is equivalent to
-	"git-diff $(git-merge-base A B) B".  You can omit any one
+	of both <commit>.  "git diff A\...B" is equivalent to
+	"git diff $(git-merge-base A B) B".  You can omit any one
 	of <commit>, which has the same effect as using HEAD instead.
 
 Just in case if you are doing something exotic, it should be
diff --git a/git-fast-export.html b/git-fast-export.html
index ec84222c8..003af0a6e 100644
--- a/git-fast-export.html
+++ b/git-fast-export.html
@@ -272,15 +272,15 @@ git-fast-export(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-fast-export [options]</em> | <em>git-fast-import</em></p>
+<p><em>git fast-export [options]</em> | <em>git fast-import</em></p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>This program dumps the given revisions in a form suitable to be piped
-into <a href="git-fast-import.html">git-fast-import(1)</a>.</p>
+into <tt>git-fast-import</tt>.</p>
 <p>You can use it as a human readable bundle replacement (see
 <a href="git-bundle.html">git-bundle(1)</a>), or as a kind of an interactive
-<a href="git-filter-branch.html">git-filter-branch(1)</a>.</p>
+<tt>git-filter-branch</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -291,7 +291,7 @@ into <a href="git-fast-import.html">git-fast-import(1)</a>.</p>
 <dd>
 <p>
         Insert <em>progress</em> statements every &lt;n&gt; objects, to be shown by
-        <a href="git-fast-import.html">git-fast-import(1)</a> during import.
+        <tt>git-fast-import</tt> during import.
 </p>
 </dd>
 <dt>
@@ -362,7 +362,7 @@ referenced by that revision range contains the string
 </div>
 <h2>Limitations</h2>
 <div class="sectionbody">
-<p>Since <a href="git-fast-import.html">git-fast-import(1)</a> cannot tag trees, you will not be
+<p>Since <tt>git-fast-import</tt> cannot tag trees, you will not be
 able to export the linux-2.6.git repository completely, as it contains
 a tag referencing a tree instead of a commit.</p>
 </div>
@@ -380,7 +380,7 @@ a tag referencing a tree instead of a commit.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:35 UTC
+Last updated 02-Jul-2008 03:01:42 UTC
 </div>
 </div>
 </body>
diff --git a/git-fast-export.txt b/git-fast-export.txt
index 277a547a0..dbc2b190e 100644
--- a/git-fast-export.txt
+++ b/git-fast-export.txt
@@ -8,23 +8,23 @@ git-fast-export - Git data exporter
 
 SYNOPSIS
 --------
-'git-fast-export [options]' | 'git-fast-import'
+'git fast-export [options]' | 'git fast-import'
 
 DESCRIPTION
 -----------
 This program dumps the given revisions in a form suitable to be piped
-into linkgit:git-fast-import[1].
+into `git-fast-import`.
 
 You can use it as a human readable bundle replacement (see
 linkgit:git-bundle[1]), or as a kind of an interactive
-linkgit:git-filter-branch[1].
+`git-filter-branch`.
 
 
 OPTIONS
 -------
 --progress=<n>::
 	Insert 'progress' statements every <n> objects, to be shown by
-	linkgit:git-fast-import[1] during import.
+	`git-fast-import` during import.
 
 --signed-tags=(verbatim|warn|strip|abort)::
 	Specify how to handle signed tags.  Since any transformation
@@ -85,7 +85,7 @@ referenced by that revision range contains the string
 Limitations
 -----------
 
-Since linkgit:git-fast-import[1] cannot tag trees, you will not be
+Since `git-fast-import` cannot tag trees, you will not be
 able to export the linux-2.6.git repository completely, as it contains
 a tag referencing a tree instead of a commit.
 
diff --git a/git-fast-import.html b/git-fast-import.html
index aedbe51e2..3a52e701a 100644
--- a/git-fast-import.html
+++ b/git-fast-import.html
@@ -272,21 +272,21 @@ git-fast-import(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p>frontend | <em>git-fast-import</em> [options]</p>
+<p>frontend | <em>git fast-import</em> [options]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>This program is usually not what the end user wants to run directly.
 Most end users want to use one of the existing frontend programs,
 which parses a specific type of foreign source and feeds the contents
-stored there to git-fast-import.</p>
+stored there to <tt>git-fast-import</tt>.</p>
 <p>fast-import reads a mixed command/data stream from standard input and
 writes one or more packfiles directly into the current repository.
 When EOF is received on standard input, fast import writes out
 updated branch and tag refs, fully updating the current repository
 with the newly imported data.</p>
 <p>The fast-import backend itself can import into an empty repository (one that
-has already been initialized by <a href="git-init.html">git-init(1)</a>) or incrementally
+has already been initialized by <tt>git-init</tt>) or incrementally
 update an existing populated repository.  Whether or not incremental
 imports are supported from a particular foreign source depends on
 the frontend program in use.</p>
@@ -383,7 +383,7 @@ the frontend program in use.</p>
         This information may be useful after importing projects
         whose total object set exceeds the 4 GiB packfile limit,
         as these commits can be used as edge points during calls
-        to <a href="git-pack-objects.html">git-pack-objects(1)</a>.
+        to <tt>git-pack-objects</tt>.
 </p>
 </dd>
 <dt>
@@ -436,7 +436,7 @@ an ideal situation, given that most conversion tools are throw-away
 <div class="sectionbody">
 <p>Like <tt>git-push</tt> or <tt>git-fetch</tt>, imports handled by fast-import are safe to
 run alongside parallel <tt>git repack -a -d</tt> or <tt>git gc</tt> invocations,
-or any other Git operation (including <tt>git prune</tt>, as loose objects
+or any other Git operation (including <tt>git-prune</tt>, as loose objects
 are never used by fast-import).</p>
 <p>fast-import does not lock the branch or tag refs it is actively importing.
 After the import, during its ref update phase, fast-import tests each
@@ -526,7 +526,7 @@ variation in formatting will cause fast-import to reject the value.</p>
 </p>
 <p>An example value is &#8220;Tue Feb 6 11:22:18 2007 -0500&#8221;.  The Git
 parser is accurate, but a little on the lenient side.  It is the
-same parser used by <a href="git-am.html">git-am(1)</a> when applying patches
+same parser used by <tt>git-am</tt> when applying patches
 received from email.</p>
 <p>Some malformed strings may be accepted as valid dates.  In some of
 these cases Git will still be able to obtain the correct date from
@@ -561,7 +561,7 @@ timezone.</p>
 <p>This particular format is supplied as its short to implement and
 may be useful to a process that wants to create a new commit
 right now, without needing to use a working directory or
-<a href="git-update-index.html">git-update-index(1)</a>.</p>
+<tt>git-update-index</tt>.</p>
 <p>If separate <tt>author</tt> and <tt>committer</tt> commands are used in a <tt>commit</tt>
 the timestamps may not match, as the system clock will be polled
 twice (once for each command).  The only way to ensure that both
@@ -984,7 +984,7 @@ recommended, as the frontend does not (easily) have access to the
 complete set of bytes which normally goes into such a signature.
 If signing is required, create lightweight tags from within fast-import with
 <tt>reset</tt>, then create the annotated versions of those tags offline
-with the standard <a href="git-tag.html">git-tag(1)</a> process.</p>
+with the standard <tt>git-tag</tt> process.</p>
 <h3><tt>reset</tt></h3>
 <p>Creates (or recreates) the named branch, optionally starting from
 a specific revision.  The reset command allows a frontend to issue
@@ -1125,7 +1125,7 @@ remove the leading part of the line, for example:</p>
 <div class="exampleblock-content">
 <div class="literalblock">
 <div class="content">
-<pre><tt>frontend | git-fast-import | sed 's/^progress //'</tt></pre>
+<pre><tt>frontend | git fast-import | sed 's/^progress //'</tt></pre>
 </div></div>
 </div></div>
 <p>Placing a <tt>progress</tt> command immediately after a <tt>checkpoint</tt> will
@@ -1174,7 +1174,7 @@ END_OF_INPUT</tt></pre>
 </div></div>
 <div class="literalblock">
 <div class="content">
-<pre><tt>$ git-fast-import &lt;in
+<pre><tt>$ git fast-import &lt;in
 fatal: Corrupt mode: M 777 inline bob
 fast-import: dumping crash report to .git/fast_import_crash_8434</tt></pre>
 </div></div>
@@ -1279,7 +1279,7 @@ with real branches imported from the source (the name <tt>TAG_FIXUP</tt>
 is not <tt>refs/heads/TAG_FIXUP</tt>).</p>
 <p>When committing fixups, consider using <tt>merge</tt> to connect the
 commit(s) which are supplying file revisions to the fixup branch.
-Doing so will allow tools such as <a href="git-blame.html">git-blame(1)</a> to track
+Doing so will allow tools such as <tt>git-blame</tt> to track
 through the real commit history and properly annotate the source
 files.</p>
 <p>After fast-import terminates the frontend will need to do <tt>rm .git/TAG_FIXUP</tt>
@@ -1301,7 +1301,7 @@ situations.</p>
 <h3>Repacking Historical Data</h3>
 <p>If you are repacking very old imported data (e.g. older than the
 last year), consider expending some extra CPU time and supplying
---window=50 (or higher) when you run <a href="git-repack.html">git-repack(1)</a>.
+--window=50 (or higher) when you run <tt>git-repack</tt>.
 This will take longer, but will also produce a smaller packfile.
 You only need to expend the effort once, and everyone using your
 project will benefit from the smaller repository.</p>
@@ -1416,7 +1416,7 @@ memory footprint (less than 2.7 MiB per active branch).</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:38 UTC
+Last updated 02-Jul-2008 03:01:43 UTC
 </div>
 </div>
 </body>
diff --git a/git-fast-import.txt b/git-fast-import.txt
index 395c055f9..70cc8e831 100644
--- a/git-fast-import.txt
+++ b/git-fast-import.txt
@@ -8,14 +8,14 @@ git-fast-import - Backend for fast Git data importers
 
 SYNOPSIS
 --------
-frontend | 'git-fast-import' [options]
+frontend | 'git fast-import' [options]
 
 DESCRIPTION
 -----------
 This program is usually not what the end user wants to run directly.
 Most end users want to use one of the existing frontend programs,
 which parses a specific type of foreign source and feeds the contents
-stored there to git-fast-import.
+stored there to `git-fast-import`.
 
 fast-import reads a mixed command/data stream from standard input and
 writes one or more packfiles directly into the current repository.
@@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
 with the newly imported data.
 
 The fast-import backend itself can import into an empty repository (one that
-has already been initialized by linkgit:git-init[1]) or incrementally
+has already been initialized by `git-init`) or incrementally
 update an existing populated repository.  Whether or not incremental
 imports are supported from a particular foreign source depends on
 the frontend program in use.
@@ -82,7 +82,7 @@ OPTIONS
 	This information may be useful after importing projects
 	whose total object set exceeds the 4 GiB packfile limit,
 	as these commits can be used as edge points during calls
-	to linkgit:git-pack-objects[1].
+	to `git-pack-objects`.
 
 --quiet::
 	Disable all non-fatal output, making fast-import silent when it
@@ -126,7 +126,7 @@ Parallel Operation
 ------------------
 Like `git-push` or `git-fetch`, imports handled by fast-import are safe to
 run alongside parallel `git repack -a -d` or `git gc` invocations,
-or any other Git operation (including `git prune`, as loose objects
+or any other Git operation (including `git-prune`, as loose objects
 are never used by fast-import).
 
 fast-import does not lock the branch or tag refs it is actively importing.
@@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.
 +
 An example value is ``Tue Feb 6 11:22:18 2007 -0500''.  The Git
 parser is accurate, but a little on the lenient side.  It is the
-same parser used by linkgit:git-am[1] when applying patches
+same parser used by `git-am` when applying patches
 received from email.
 +
 Some malformed strings may be accepted as valid dates.  In some of
@@ -256,7 +256,7 @@ timezone.
 This particular format is supplied as its short to implement and
 may be useful to a process that wants to create a new commit
 right now, without needing to use a working directory or
-linkgit:git-update-index[1].
+`git-update-index`.
 +
 If separate `author` and `committer` commands are used in a `commit`
 the timestamps may not match, as the system clock will be polled
@@ -654,7 +654,7 @@ recommended, as the frontend does not (easily) have access to the
 complete set of bytes which normally goes into such a signature.
 If signing is required, create lightweight tags from within fast-import with
 `reset`, then create the annotated versions of those tags offline
-with the standard linkgit:git-tag[1] process.
+with the standard `git-tag` process.
 
 `reset`
 ~~~~~~~
@@ -803,7 +803,7 @@ Callers may wish to process the output through a tool such as sed to
 remove the leading part of the line, for example:
 
 ====
-	frontend | git-fast-import | sed 's/^progress //'
+	frontend | git fast-import | sed 's/^progress //'
 ====
 
 Placing a `progress` command immediately after a `checkpoint` will
@@ -851,7 +851,7 @@ An example crash:
 	M 777 inline bob
 	END_OF_INPUT
 
-	$ git-fast-import <in
+	$ git fast-import <in
 	fatal: Corrupt mode: M 777 inline bob
 	fast-import: dumping crash report to .git/fast_import_crash_8434
 
@@ -955,7 +955,7 @@ is not `refs/heads/TAG_FIXUP`).
 
 When committing fixups, consider using `merge` to connect the
 commit(s) which are supplying file revisions to the fixup branch.
-Doing so will allow tools such as linkgit:git-blame[1] to track
+Doing so will allow tools such as `git-blame` to track
 through the real commit history and properly annotate the source
 files.
 
@@ -984,7 +984,7 @@ Repacking Historical Data
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 If you are repacking very old imported data (e.g. older than the
 last year), consider expending some extra CPU time and supplying
-\--window=50 (or higher) when you run linkgit:git-repack[1].
+\--window=50 (or higher) when you run `git-repack`.
 This will take longer, but will also produce a smaller packfile.
 You only need to expend the effort once, and everyone using your
 project will benefit from the smaller repository.
diff --git a/git-fetch-pack.html b/git-fetch-pack.html
index 05d967ae4..eaf2afc8c 100644
--- a/git-fetch-pack.html
+++ b/git-fetch-pack.html
@@ -272,17 +272,17 @@ git-fetch-pack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-fetch-pack</em> [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=&lt;git-upload-pack&gt;] [--depth=&lt;n&gt;] [--no-progress] [-v] [&lt;host&gt;:]&lt;directory&gt; [&lt;refs&gt;&#8230;]</p>
+<p><em>git fetch-pack</em> [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=&lt;git-upload-pack&gt;] [--depth=&lt;n&gt;] [--no-progress] [-v] [&lt;host&gt;:]&lt;directory&gt; [&lt;refs&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Usually you would want to use <a href="git-fetch.html">git-fetch(1)</a> which is a
-higher level wrapper of this command instead.</p>
-<p>Invokes <em>git-upload-pack</em> on a potentially remote repository,
+<p>Usually you would want to use <tt>git-fetch</tt>, which is a
+higher level wrapper of this command, instead.</p>
+<p>Invokes <tt>git-upload-pack</tt> on a possibly remote repository
 and asks it to send objects missing from this repository, to
 update the named heads.  The list of commits available locally
 is found out by scanning local $GIT_DIR/refs/ and sent to
-<em>git-upload-pack</em> running on the other end.</p>
+<tt>git-upload-pack</tt> running on the other end.</p>
 <p>This command degenerates to download everything to complete the
 asked refs from the remote side when the local side does not
 have a common ancestor commit.</p>
@@ -306,7 +306,7 @@ have a common ancestor commit.</p>
 </dt>
 <dd>
 <p>
-        Pass <em>-q</em> flag to <em>git-unpack-objects</em>; this makes the
+        Pass <em>-q</em> flag to <tt>git-unpack-objects</tt>; this makes the
         cloning process less verbose.
 </p>
 </dd>
@@ -318,7 +318,7 @@ have a common ancestor commit.</p>
 </dt>
 <dd>
 <p>
-        Do not invoke <em>git-unpack-objects</em> on received data, but
+        Do not invoke <tt>git-unpack-objects</tt> on received data, but
         create a single packfile out of it instead, and store it
         in the object database. If provided twice then the pack is
         locked against repacking.
@@ -349,7 +349,7 @@ have a common ancestor commit.</p>
 </dt>
 <dd>
 <p>
-        Use this to specify the path to <em>git-upload-pack</em> on the
+        Use this to specify the path to <tt>git-upload-pack</tt> on the
         remote side, if is not found on your $PATH.
         Installations of sshd ignores the user's environment
         setup scripts for login shells (e.g. .bash_profile) and
@@ -399,7 +399,7 @@ have a common ancestor commit.</p>
 <dd>
 <p>
         A remote host that houses the repository.  When this
-        part is specified, <em>git-upload-pack</em> is invoked via
+        part is specified, <tt>git-upload-pack</tt> is invoked via
         ssh.
 </p>
 </dd>
@@ -437,7 +437,7 @@ have a common ancestor commit.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:34 UTC
+Last updated 02-Jul-2008 03:01:43 UTC
 </div>
 </div>
 </body>
diff --git a/git-fetch-pack.txt b/git-fetch-pack.txt
index 282fcaf17..a069f8d9a 100644
--- a/git-fetch-pack.txt
+++ b/git-fetch-pack.txt
@@ -8,18 +8,18 @@ git-fetch-pack - Receive missing objects from another repository
 
 SYNOPSIS
 --------
-'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
+'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
 
 DESCRIPTION
 -----------
-Usually you would want to use linkgit:git-fetch[1] which is a
-higher level wrapper of this command instead.
+Usually you would want to use `git-fetch`, which is a
+higher level wrapper of this command, instead.
 
-Invokes 'git-upload-pack' on a potentially remote repository,
+Invokes `git-upload-pack` on a possibly remote repository
 and asks it to send objects missing from this repository, to
 update the named heads.  The list of commits available locally
 is found out by scanning local $GIT_DIR/refs/ and sent to
-'git-upload-pack' running on the other end.
+`git-upload-pack` running on the other end.
 
 This command degenerates to download everything to complete the
 asked refs from the remote side when the local side does not
@@ -33,12 +33,12 @@ OPTIONS
 
 -q::
 --quiet::
-	Pass '-q' flag to 'git-unpack-objects'; this makes the
+	Pass '-q' flag to `git-unpack-objects`; this makes the
 	cloning process less verbose.
 
 -k::
 --keep::
-	Do not invoke 'git-unpack-objects' on received data, but
+	Do not invoke `git-unpack-objects` on received data, but
 	create a single packfile out of it instead, and store it
 	in the object database. If provided twice then the pack is
 	locked against repacking.
@@ -54,7 +54,7 @@ OPTIONS
 	otherwise determine the tags this option made available.
 
 --upload-pack=<git-upload-pack>::
-	Use this to specify the path to 'git-upload-pack' on the
+	Use this to specify the path to `git-upload-pack` on the
 	remote side, if is not found on your $PATH.
 	Installations of sshd ignores the user's environment
 	setup scripts for login shells (e.g. .bash_profile) and
@@ -79,7 +79,7 @@ OPTIONS
 
 <host>::
 	A remote host that houses the repository.  When this
-	part is specified, 'git-upload-pack' is invoked via
+	part is specified, `git-upload-pack` is invoked via
 	ssh.
 
 <directory>::
diff --git a/git-fetch.html b/git-fetch.html
index 3f3acebdd..2f4cf69ee 100644
--- a/git-fetch.html
+++ b/git-fetch.html
@@ -272,7 +272,7 @@ git-fetch(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-fetch</em> &lt;options&gt; &lt;repository&gt; &lt;refspec&gt;&#8230;</p>
+<p><em>git fetch</em> &lt;options&gt; &lt;repository&gt; &lt;refspec&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -280,7 +280,7 @@ git-fetch(1) Manual Page
 the objects necessary to complete them.</p>
 <p>The ref names and their object names of fetched refs are stored
 in <tt>.git/FETCH_HEAD</tt>.  This information is left for a later merge
-operation done by "git merge".</p>
+operation done by <tt>git-merge</tt>.</p>
 <p>When &lt;refspec&gt; stores the fetched result in tracking branches,
 the tags that point at these branches are automatically
 followed.  This is done by first fetching from the remote using
@@ -733,7 +733,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:36 UTC
+Last updated 02-Jul-2008 03:01:44 UTC
 </div>
 </div>
 </body>
diff --git a/git-fetch.txt b/git-fetch.txt
index 489b2b17e..b22556641 100644
--- a/git-fetch.txt
+++ b/git-fetch.txt
@@ -8,7 +8,7 @@ git-fetch - Download objects and refs from another repository
 
 SYNOPSIS
 --------
-'git-fetch' <options> <repository> <refspec>...
+'git fetch' <options> <repository> <refspec>...
 
 
 DESCRIPTION
@@ -18,7 +18,7 @@ the objects necessary to complete them.
 
 The ref names and their object names of fetched refs are stored
 in `.git/FETCH_HEAD`.  This information is left for a later merge
-operation done by "git merge".
+operation done by `git-merge`.
 
 When <refspec> stores the fetched result in tracking branches,
 the tags that point at these branches are automatically
diff --git a/git-filter-branch.html b/git-filter-branch.html
index 46e289f22..7cb33fa67 100644
--- a/git-filter-branch.html
+++ b/git-filter-branch.html
@@ -273,7 +273,7 @@ git-filter-branch(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-filter-branch</em> [--env-filter &lt;command&gt;] [--tree-filter &lt;command&gt;]
+<div class="content"><em>git filter-branch</em> [--env-filter &lt;command&gt;] [--tree-filter &lt;command&gt;]
         [--index-filter &lt;command&gt;] [--parent-filter &lt;command&gt;]
         [--msg-filter &lt;command&gt;] [--commit-filter &lt;command&gt;]
         [--tag-name-filter &lt;command&gt;] [--subdirectory-filter &lt;directory&gt;]
@@ -369,7 +369,7 @@ multiple commits.</p>
         This is the filter for rewriting the commit's parent list.
         It will receive the parent string on stdin and shall output
         the new parent string on stdout.  The parent string is in
-        a format accepted by <a href="git-commit-tree.html">git-commit-tree(1)</a>: empty for
+        the format described in <a href="git-commit-tree.html">git-commit-tree(1)</a>: empty for
         the initial commit, "-p parent" for a normal commit and
         "-p parent1 -p parent2 -p parent3 &#8230;" for a merge commit.
 </p>
@@ -392,7 +392,7 @@ multiple commits.</p>
 <p>
         This is the filter for performing the commit.
         If this filter is specified, it will be called instead of the
-        <a href="git-commit-tree.html">git-commit-tree(1)</a> command, with arguments of the form
+        <tt>git-commit-tree</tt> command, with arguments of the form
         "&lt;TREE_ID&gt; [-p &lt;PARENT_COMMIT_ID&gt;]&#8230;" and the log message on
         stdin.  The commit id is expected on stdout.
 </p>
@@ -402,7 +402,7 @@ have all of them as parents.</p>
 <p>You can use the <em>map</em> convenience function in this filter, and other
 convenience functions, too.  For example, calling <em>skip_commit "$@"</em>
 will leave out the current commit (but not its changes! If you want
-that, use <a href="git-rebase.html">git-rebase(1)</a> instead).</p>
+that, use <tt>git-rebase</tt> instead).</p>
 </dd>
 <dt>
 --tag-name-filter &lt;command&gt;
@@ -481,7 +481,7 @@ to other tags will be rewritten to point to the underlying commit.</p>
 <dd>
 <p>
         When options are given after the new branch name, they will
-        be passed to <a href="git-rev-list.html">git-rev-list(1)</a>.  Only commits in the resulting
+        be passed to <tt>git-rev-list</tt>.  Only commits in the resulting
         output will be filtered, although the filtered commits can still
         reference parents which are outside of that set.
 </p>
@@ -568,12 +568,12 @@ be removed this way:</p>
 </div></div>
 <p>To restrict rewriting to only part of the history, specify a revision
 range in addition to the new branch name.  The new branch name will
-point to the top-most revision that a <em>git rev-list</em> of this range
+point to the top-most revision that a <tt>git-rev-list</tt> of this range
 will print.</p>
 <p><strong>NOTE</strong> the changes introduced by the commits, and which are not reverted
 by subsequent commits, will still be in the rewritten branch. If you want
 to throw out _changes_ together with the commits, you should use the
-interactive mode of <a href="git-rebase.html">git-rebase(1)</a>.</p>
+interactive mode of <tt>git-rebase</tt>.</p>
 <p>Consider this history:</p>
 <div class="listingblock">
 <div class="content">
@@ -617,7 +617,7 @@ and the git list &lt;git@vger.kernel.org&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:37 UTC
+Last updated 02-Jul-2008 03:01:45 UTC
 </div>
 </div>
 </body>
diff --git a/git-filter-branch.txt b/git-filter-branch.txt
index ea77f1fce..a9388e0e2 100644
--- a/git-filter-branch.txt
+++ b/git-filter-branch.txt
@@ -8,7 +8,7 @@ git-filter-branch - Rewrite branches
 SYNOPSIS
 --------
 [verse]
-'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
+'git filter-branch' [--env-filter <command>] [--tree-filter <command>]
 	[--index-filter <command>] [--parent-filter <command>]
 	[--msg-filter <command>] [--commit-filter <command>]
 	[--tag-name-filter <command>] [--subdirectory-filter <directory>]
@@ -95,7 +95,7 @@ OPTIONS
 	This is the filter for rewriting the commit's parent list.
 	It will receive the parent string on stdin and shall output
 	the new parent string on stdout.  The parent string is in
-	a format accepted by linkgit:git-commit-tree[1]: empty for
+	the format described in linkgit:git-commit-tree[1]: empty for
 	the initial commit, "-p parent" for a normal commit and
 	"-p parent1 -p parent2 -p parent3 ..." for a merge commit.
 
@@ -108,7 +108,7 @@ OPTIONS
 --commit-filter <command>::
 	This is the filter for performing the commit.
 	If this filter is specified, it will be called instead of the
-	linkgit:git-commit-tree[1] command, with arguments of the form
+	`git-commit-tree` command, with arguments of the form
 	"<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
 	stdin.  The commit id is expected on stdout.
 +
@@ -119,7 +119,7 @@ have all of them as parents.
 You can use the 'map' convenience function in this filter, and other
 convenience functions, too.  For example, calling 'skip_commit "$@"'
 will leave out the current commit (but not its changes! If you want
-that, use linkgit:git-rebase[1] instead).
+that, use `git-rebase` instead).
 
 --tag-name-filter <command>::
 	This is the filter for rewriting tag names. When passed,
@@ -169,7 +169,7 @@ to other tags will be rewritten to point to the underlying commit.
 
 <rev-list-options>::
 	When options are given after the new branch name, they will
-	be passed to linkgit:git-rev-list[1].  Only commits in the resulting
+	be passed to `git-rev-list`.  Only commits in the resulting
 	output will be filtered, although the filtered commits can still
 	reference parents which are outside of that set.
 
@@ -266,13 +266,13 @@ git filter-branch --msg-filter '
 
 To restrict rewriting to only part of the history, specify a revision
 range in addition to the new branch name.  The new branch name will
-point to the top-most revision that a 'git rev-list' of this range
+point to the top-most revision that a `git-rev-list` of this range
 will print.
 
 *NOTE* the changes introduced by the commits, and which are not reverted
 by subsequent commits, will still be in the rewritten branch. If you want
 to throw out _changes_ together with the commits, you should use the
-interactive mode of linkgit:git-rebase[1].
+interactive mode of `git-rebase`.
 
 
 Consider this history:
diff --git a/git-fmt-merge-msg.html b/git-fmt-merge-msg.html
index 962bc761f..a9f27032c 100644
--- a/git-fmt-merge-msg.html
+++ b/git-fmt-merge-msg.html
@@ -273,8 +273,8 @@ git-fmt-merge-msg(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content">git-fmt-merge-msg [--log | --no-log] &lt;$GIT_DIR/FETCH_HEAD
-git-fmt-merge-msg [--log | --no-log] -F &lt;file&gt;</div></div>
+<div class="content"><em>git fmt-merge-msg</em> [--log | --no-log] &lt;$GIT_DIR/FETCH_HEAD
+<em>git fmt-merge-msg</em> [--log | --no-log] -F &lt;file&gt;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -373,7 +373,7 @@ merge.summary
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:38 UTC
+Last updated 02-Jul-2008 03:01:46 UTC
 </div>
 </div>
 </body>
diff --git a/git-fmt-merge-msg.txt b/git-fmt-merge-msg.txt
index 2a7cfb980..ddb89f8d6 100644
--- a/git-fmt-merge-msg.txt
+++ b/git-fmt-merge-msg.txt
@@ -9,8 +9,8 @@ git-fmt-merge-msg - Produce a merge commit message
 SYNOPSIS
 --------
 [verse]
-git-fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
-git-fmt-merge-msg [--log | --no-log] -F <file>
+'git fmt-merge-msg' [--log | --no-log] <$GIT_DIR/FETCH_HEAD
+'git fmt-merge-msg' [--log | --no-log] -F <file>
 
 DESCRIPTION
 -----------
diff --git a/git-for-each-ref.html b/git-for-each-ref.html
index 60bc12de7..4b0a174b7 100644
--- a/git-for-each-ref.html
+++ b/git-for-each-ref.html
@@ -273,7 +273,7 @@ git-for-each-ref(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-for-each-ref</em> [--count=&lt;count&gt;] [--shell|--perl|--python|--tcl]
+<div class="content"><em>git for-each-ref</em> [--count=&lt;count&gt;] [--shell|--perl|--python|--tcl]
                    [--sort=&lt;key&gt;]* [--format=&lt;format&gt;] [&lt;pattern&gt;&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -428,7 +428,7 @@ the date by adding one of <tt>:default</tt>, <tt>:relative</tt>, <tt>:short</tt>
 <div class="content">
 <pre><tt>#!/bin/sh
 
-git-for-each-ref --count=3 --sort='-*authordate' \
+git for-each-ref --count=3 --sort='-*authordate' \
 --format='From: %(*authorname) %(*authoremail)
 Subject: %(*subject)
 Date: %(*authordate)
@@ -443,7 +443,7 @@ demonstrating the use of --shell.  List the prefixes of all heads::</p>
 <div class="content">
 <pre><tt>#!/bin/sh
 
-git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
 while read entry
 do
         eval "$entry"
@@ -496,7 +496,7 @@ Its message reads as:
         fi
 '
 
-eval=`git-for-each-ref --shell --format="$fmt" \
+eval=`git for-each-ref --shell --format="$fmt" \
         --sort='*objecttype' \
         --sort=-taggerdate \
         refs/tags`
@@ -505,7 +505,7 @@ eval "$eval"</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:39 UTC
+Last updated 02-Jul-2008 03:01:46 UTC
 </div>
 </div>
 </body>
diff --git a/git-for-each-ref.txt b/git-for-each-ref.txt
index b347bfbb1..29c29f883 100644
--- a/git-for-each-ref.txt
+++ b/git-for-each-ref.txt
@@ -8,7 +8,7 @@ git-for-each-ref - Output information on each ref
 SYNOPSIS
 --------
 [verse]
-'git-for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
+'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
 		   [--sort=<key>]\* [--format=<format>] [<pattern>...]
 
 DESCRIPTION
@@ -119,7 +119,7 @@ An example directly producing formatted text.  Show the most recent
 ------------
 #!/bin/sh
 
-git-for-each-ref --count=3 --sort='-*authordate' \
+git for-each-ref --count=3 --sort='-*authordate' \
 --format='From: %(*authorname) %(*authoremail)
 Subject: %(*subject)
 Date: %(*authordate)
@@ -135,7 +135,7 @@ demonstrating the use of --shell.  List the prefixes of all heads::
 ------------
 #!/bin/sh
 
-git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
+git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
 while read entry
 do
 	eval "$entry"
@@ -189,7 +189,7 @@ Its message reads as:
 	fi
 '
 
-eval=`git-for-each-ref --shell --format="$fmt" \
+eval=`git for-each-ref --shell --format="$fmt" \
 	--sort='*objecttype' \
 	--sort=-taggerdate \
 	refs/tags`
diff --git a/git-format-patch.html b/git-format-patch.html
index a9b84cf42..b4131ca91 100644
--- a/git-format-patch.html
+++ b/git-format-patch.html
@@ -273,7 +273,7 @@ git-format-patch(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-format-patch</em> [-k] [-o &lt;dir&gt; | --stdout] [--thread]
+<div class="content"><em>git format-patch</em> [-k] [-o &lt;dir&gt; | --stdout] [--thread]
                    [--attach[=&lt;boundary&gt;] | --inline[=&lt;boundary&gt;]]
                    [-s | --signoff] [&lt;common diff options&gt;]
                    [-n | --numbered | -N | --no-numbered]
@@ -290,7 +290,7 @@ git-format-patch(1) Manual Page
 <p>Prepare each commit with its patch in
 one file per commit, formatted to resemble UNIX mailbox format.
 The output of this command is convenient for e-mail submission or
-for use with <a href="git-am.html">git-am(1)</a>.</p>
+for use with <tt>git-am</tt>.</p>
 <p>There are two ways to specify which commits to operate on.</p>
 <ol>
 <li>
@@ -326,7 +326,7 @@ output, unless the --stdout option is specified.</p>
 they are created in the current working directory.</p>
 <p>If -n is specified, instead of "[PATCH] Subject", the first line
 is formatted as "[PATCH n/m] Subject".</p>
-<p>If given --thread, git-format-patch will generate In-Reply-To and
+<p>If given --thread, <tt>git-format-patch</tt> will generate In-Reply-To and
 References headers to make the second and subsequent patch mails appear
 as replies to the first mail; this also generates a Message-Id header to
 reference.</p>
@@ -806,7 +806,7 @@ reference.</p>
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 -&lt;n&gt;
@@ -1103,7 +1103,7 @@ as e-mailable patches:
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:40 UTC
+Last updated 02-Jul-2008 03:01:46 UTC
 </div>
 </div>
 </body>
diff --git a/git-format-patch.txt b/git-format-patch.txt
index 4dafa39a9..894b82d6b 100644
--- a/git-format-patch.txt
+++ b/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e-mail submission
 SYNOPSIS
 --------
 [verse]
-'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
+'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
 		   [--attach[=<boundary>] | --inline[=<boundary>]]
 		   [-s | --signoff] [<common diff options>]
 		   [-n | --numbered | -N | --no-numbered]
@@ -27,7 +27,7 @@ DESCRIPTION
 Prepare each commit with its patch in
 one file per commit, formatted to resemble UNIX mailbox format.
 The output of this command is convenient for e-mail submission or
-for use with linkgit:git-am[1].
+for use with `git-am`.
 
 There are two ways to specify which commits to operate on.
 
@@ -61,7 +61,7 @@ they are created in the current working directory.
 If -n is specified, instead of "[PATCH] Subject", the first line
 is formatted as "[PATCH n/m] Subject".
 
-If given --thread, git-format-patch will generate In-Reply-To and
+If given --thread, `git-format-patch` will generate In-Reply-To and
 References headers to make the second and subsequent patch mails appear
 as replies to the first mail; this also generates a Message-Id header to
 reference.
diff --git a/git-fsck-objects.html b/git-fsck-objects.html
index 64d0eccae..983cdd7e8 100644
--- a/git-fsck-objects.html
+++ b/git-fsck-objects.html
@@ -272,7 +272,7 @@ git-fsck-objects(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-fsck-objects</em> &#8230;</p>
+<p><em>git fsck-objects</em> &#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,7 +281,7 @@ documentation of that command.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:43 UTC
+Last updated 02-Jul-2008 03:01:46 UTC
 </div>
 </div>
 </body>
diff --git a/git-fsck-objects.txt b/git-fsck-objects.txt
index 6e9f71764..965a8279c 100644
--- a/git-fsck-objects.txt
+++ b/git-fsck-objects.txt
@@ -8,7 +8,7 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
 
 SYNOPSIS
 --------
-'git-fsck-objects' ...
+'git fsck-objects' ...
 
 DESCRIPTION
 -----------
diff --git a/git-fsck.html b/git-fsck.html
index 751a5ad19..95657d08c 100644
--- a/git-fsck.html
+++ b/git-fsck.html
@@ -273,7 +273,7 @@ git-fsck(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-fsck</em> [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
+<div class="content"><em>git fsck</em> [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
          [--full] [--strict] [--verbose] [--lost-found] [&lt;object&gt;*]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -290,7 +290,7 @@ git-fsck(1) Manual Page
 <p>
         An object to treat as the head of an unreachability trace.
 </p>
-<p>If no objects are given, git-fsck defaults to using the
+<p>If no objects are given, <tt>git-fsck</tt> defaults to using the
 index file, all SHA1 references in .git/refs/*, and all reflogs (unless
 --no-reflogs is given) as heads.</p>
 </dd>
@@ -394,14 +394,14 @@ that aren't readable from any of the specified head nodes.</p>
 <p>So for example</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-fsck --unreachable HEAD $(cat .git/refs/heads/*)</tt></pre>
+<pre><tt>git fsck --unreachable HEAD $(cat .git/refs/heads/*)</tt></pre>
 </div></div>
 <p>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 <tt>git-fsck</tt> is happy, you
 do have a valid tree.</p>
 <p>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 <tt>rsync</tt> with some other site in
 the hopes that somebody else has the object you have corrupted).</p>
 <p>Of course, "valid tree" doesn't mean that it wasn't generated by some
 evil person, and the end result might be crap. git is a revision
@@ -522,7 +522,7 @@ GIT_ALTERNATE_OBJECT_DIRECTORIES
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:43 UTC
+Last updated 02-Jul-2008 03:01:46 UTC
 </div>
 </div>
 </body>
diff --git a/git-fsck.txt b/git-fsck.txt
index 9846c859c..ef4ceb3df 100644
--- a/git-fsck.txt
+++ b/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
diff --git a/git-gc.html b/git-gc.html
index df3919e57..97eec8e0a 100644
--- a/git-gc.html
+++ b/git-gc.html
@@ -272,14 +272,14 @@ git-gc(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-gc</em> [--aggressive] [--auto] [--quiet]</p>
+<p><em>git gc</em> [--aggressive] [--auto] [--quiet]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
 performance) and removing unreachable objects which may have been
-created from prior invocations of <a href="git-add.html">git-add(1)</a>.</p>
+created from prior invocations of <tt>git-add</tt>.</p>
 <p>Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
 operating performance.</p>
@@ -299,9 +299,9 @@ disable this behavior permanently without further considerations, just do:</p>
 </dt>
 <dd>
 <p>
-        Usually <em>git-gc</em> runs very quickly while providing good disk
+        Usually <tt>git-gc</tt> runs very quickly while providing good disk
         space utilization and performance.  This option will cause
-        git-gc to more aggressively optimize the repository at the expense
+        <tt>git-gc</tt> to more aggressively optimize the repository at the expense
         of taking much more time.  The effects of this optimization are
         persistent, so this option only needs to be used occasionally; every
         few hundred changesets or so.
@@ -312,7 +312,7 @@ disable this behavior permanently without further considerations, just do:</p>
 </dt>
 <dd>
 <p>
-        With this option, <tt>git gc</tt> checks whether any housekeeping is
+        With this option, <tt>git-gc</tt> checks whether any housekeeping is
         required; if not, it exits without performing any work.
         Some git commands run <tt>git gc --auto</tt> after performing
         operations that could create many loose objects.
@@ -361,7 +361,7 @@ kept.  This defaults to 60 days.</p>
 how long records of conflicted merge you have not resolved are
 kept.  This defaults to 15 days.</p>
 <p>The optional configuration variable <em>gc.packrefs</em> determines if
-<tt>git gc</tt> runs <tt>git-pack-refs</tt>. This can be set to "nobare" to enable
+<tt>git-gc</tt> runs <tt>git-pack-refs</tt>. This can be set to "nobare" to enable
 it within all non-bare repos or it can be set to a boolean value.
 This defaults to true.</p>
 <p>The optional configuration variable <em>gc.aggressiveWindow</em> controls how
@@ -376,10 +376,10 @@ default is "2 weeks ago".</p>
 </div>
 <h2>Notes</h2>
 <div class="sectionbody">
-<p>git-gc tries very hard to be safe about the garbage it collects. In
+<p><tt>git-gc</tt> tries very hard to be safe about the garbage it collects. In
 particular, it will keep not only objects referenced by your current set
 of branches and tags, but also objects referenced by the index, remote
-tracking branches, refs saved by <a href="git-filter-branch.html">git-filter-branch(1)</a> in
+tracking branches, refs saved by <tt>git-filter-branch</tt> in
 refs/original/, or reflogs (which may references commits in branches
 that were later amended or rewound).</p>
 <p>If you are expecting some objects to be collected and they aren't, check
@@ -403,7 +403,7 @@ remove those references.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:43 UTC
+Last updated 02-Jul-2008 03:01:47 UTC
 </div>
 </div>
 </body>
diff --git a/git-gc.txt b/git-gc.txt
index 6ace615d8..0cce3894c 100644
--- a/git-gc.txt
+++ b/git-gc.txt
@@ -8,14 +8,14 @@ git-gc - Cleanup unnecessary files and optimize the local repository
 
 SYNOPSIS
 --------
-'git-gc' [--aggressive] [--auto] [--quiet]
+'git gc' [--aggressive] [--auto] [--quiet]
 
 DESCRIPTION
 -----------
 Runs a number of housekeeping tasks within the current repository,
 such as compressing file revisions (to reduce disk space and increase
 performance) and removing unreachable objects which may have been
-created from prior invocations of linkgit:git-add[1].
+created from prior invocations of `git-add`.
 
 Users are encouraged to run this task on a regular basis within
 each repository to maintain good disk space utilization and good
@@ -33,15 +33,15 @@ OPTIONS
 -------
 
 --aggressive::
-	Usually 'git-gc' runs very quickly while providing good disk
+	Usually `git-gc` runs very quickly while providing good disk
 	space utilization and performance.  This option will cause
-	git-gc to more aggressively optimize the repository at the expense
+	`git-gc` to more aggressively optimize the repository at the expense
 	of taking much more time.  The effects of this optimization are
 	persistent, so this option only needs to be used occasionally; every
 	few hundred changesets or so.
 
 --auto::
-	With this option, `git gc` checks whether any housekeeping is
+	With this option, `git-gc` checks whether any housekeeping is
 	required; if not, it exits without performing any work.
 	Some git commands run `git gc --auto` after performing
 	operations that could create many loose objects.
@@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
 kept.  This defaults to 15 days.
 
 The optional configuration variable 'gc.packrefs' determines if
-`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
 it within all non-bare repos or it can be set to a boolean value.
 This defaults to true.
 
@@ -108,10 +108,10 @@ default is "2 weeks ago".
 Notes
 -----
 
-git-gc tries very hard to be safe about the garbage it collects. In
+`git-gc` tries very hard to be safe about the garbage it collects. In
 particular, it will keep not only objects referenced by your current set
 of branches and tags, but also objects referenced by the index, remote
-tracking branches, refs saved by linkgit:git-filter-branch[1] in
+tracking branches, refs saved by `git-filter-branch` in
 refs/original/, or reflogs (which may references commits in branches
 that were later amended or rewound).
 
diff --git a/git-get-tar-commit-id.html b/git-get-tar-commit-id.html
index e966680fe..50a9ecaeb 100644
--- a/git-get-tar-commit-id.html
+++ b/git-get-tar-commit-id.html
@@ -272,16 +272,16 @@ git-get-tar-commit-id(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-get-tar-commit-id</em> &lt; &lt;tarfile&gt;</p>
+<p><em>git get-tar-commit-id</em> &lt; &lt;tarfile&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Acts as a filter, extracting the commit ID stored in archives created by
-<a href="git-archive.html">git-archive(1)</a>.  It reads only the first 1024 bytes of input, thus its
+<tt>git-archive</tt>.  It reads only the first 1024 bytes of input, thus its
 runtime is not influenced by the size of &lt;tarfile&gt; very much.</p>
-<p>If no commit ID is found, git-get-tar-commit-id quietly exists with a
+<p>If no commit ID is found, <tt>git-get-tar-commit-id</tt> quietly exists with a
 return code of 1.  This can happen if &lt;tarfile&gt; had not been created
-using git-archive or if the first parameter of git-archive had been
+using <tt>git-archive</tt> or if the first parameter of <tt>git-archive</tt> had been
 a tree ID instead of a commit ID or tag.</p>
 </div>
 <h2>Author</h2>
@@ -298,7 +298,7 @@ a tree ID instead of a commit ID or tag.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:44 UTC
+Last updated 02-Jul-2008 03:01:47 UTC
 </div>
 </div>
 </body>
diff --git a/git-get-tar-commit-id.txt b/git-get-tar-commit-id.txt
index c13bf9869..50dfdfa19 100644
--- a/git-get-tar-commit-id.txt
+++ b/git-get-tar-commit-id.txt
@@ -8,18 +8,18 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch
 
 SYNOPSIS
 --------
-'git-get-tar-commit-id' < <tarfile>
+'git get-tar-commit-id' < <tarfile>
 
 
 DESCRIPTION
 -----------
 Acts as a filter, extracting the commit ID stored in archives created by
-linkgit:git-archive[1].  It reads only the first 1024 bytes of input, thus its
+`git-archive`.  It reads only the first 1024 bytes of input, thus its
 runtime is not influenced by the size of <tarfile> very much.
 
-If no commit ID is found, git-get-tar-commit-id quietly exists with a
+If no commit ID is found, `git-get-tar-commit-id` quietly exists with a
 return code of 1.  This can happen if <tarfile> had not been created
-using git-archive or if the first parameter of git-archive had been
+using `git-archive` or if the first parameter of `git-archive` had been
 a tree ID instead of a commit ID or tag.
 
 
diff --git a/git-grep.html b/git-grep.html
index 474a61e38..7d3d200d6 100644
--- a/git-grep.html
+++ b/git-grep.html
@@ -273,7 +273,7 @@ git-grep(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-grep</em> [--cached]
+<div class="content"><em>git grep</em> [--cached]
            [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
            [-v | --invert-match] [-h|-H] [--full-name]
            [-E | --extended-regexp] [-G | --basic-regexp]
@@ -440,7 +440,7 @@ registered in the index file, or given tree objects.</p>
 <p>
         Instead of showing every matched line, show only the
         names of files that contain (or do not contain) matches.
-        For better compatibility with git-diff, --name-only is a
+        For better compatibility with <tt>git-diff</tt>, --name-only is a
         synonym for --files-with-matches.
 </p>
 </dd>
@@ -581,7 +581,7 @@ revamped by Junio C Hamano.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:41 UTC
+Last updated 02-Jul-2008 03:01:47 UTC
 </div>
 </div>
 </body>
diff --git a/git-grep.txt b/git-grep.txt
index 1b646b73f..25cb64957 100644
--- a/git-grep.txt
+++ b/git-grep.txt
@@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern
 SYNOPSIS
 --------
 [verse]
-'git-grep' [--cached]
+'git grep' [--cached]
 	   [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
 	   [-v | --invert-match] [-h|-H] [--full-name]
 	   [-E | --extended-regexp] [-G | --basic-regexp]
@@ -91,7 +91,7 @@ OPTIONS
 --files-without-match::
 	Instead of showing every matched line, show only the
 	names of files that contain (or do not contain) matches.
-	For better compatibility with git-diff, --name-only is a
+	For better compatibility with `git-diff`, --name-only is a
 	synonym for --files-with-matches.
 
 -c::
diff --git a/git-gui.html b/git-gui.html
index 844decf30..b7667a0eb 100644
--- a/git-gui.html
+++ b/git-gui.html
@@ -276,17 +276,17 @@ git-gui(1) Manual Page
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>A Tcl/Tk based graphical user interface to Git.  git-gui focuses
+<p>A Tcl/Tk based graphical user interface to Git.  <tt>git-gui</tt> focuses
 on allowing users to make changes to their repository by making
 new commits, amending existing ones, creating branches, performing
 local merges, and fetching/pushing to remote repositories.</p>
-<p>Unlike <a href="gitk.html">gitk(1)</a>, git-gui focuses on commit generation
-and single file annotation, and does not show project history.
-It does however supply menu actions to start a gitk session from
-within git-gui.</p>
-<p>git-gui is known to work on all popular UNIX systems, Mac OS X,
+<p>Unlike <tt>gitk</tt>, <tt>git-gui</tt> focuses on commit generation
+and single file annotation and does not show project history.
+It does however supply menu actions to start a <tt>gitk</tt> session from
+within <tt>git-gui</tt>.</p>
+<p><tt>git-gui</tt> is known to work on all popular UNIX systems, Mac OS X,
 and Windows (under both Cygwin and MSYS).  To the extent possible
-OS specific user interface guidelines are followed, making git-gui
+OS specific user interface guidelines are followed, making <tt>git-gui</tt>
 a fairly native interface for users.</p>
 </div>
 <h2>COMMANDS</h2>
@@ -316,7 +316,7 @@ citool
 </dt>
 <dd>
 <p>
-        Start git-gui and arrange to make exactly one commit before
+        Start <tt>git-gui</tt> and arrange to make exactly one commit before
         exiting and returning to the shell.  The interface is limited
         to only commit actions, slightly reducing the application's
         startup time and simplifying the menubar.
@@ -327,7 +327,7 @@ version
 </dt>
 <dd>
 <p>
-        Display the currently running version of git-gui.
+        Display the currently running version of <tt>git-gui</tt>.
 </p>
 </dd>
 </dl>
@@ -397,17 +397,17 @@ git gui browser maint
 <p>
         The git repository browser.  Shows branches, commit history
         and file differences.  gitk is the utility started by
-        git-gui's Repository Visualize actions.
+        <tt>git-gui</tt>'s Repository Visualize actions.
 </p>
 </dd>
 </dl>
 </div>
 <h2>Other</h2>
 <div class="sectionbody">
-<p>git-gui is actually maintained as an independent project, but stable
+<p><tt>git-gui</tt> is actually maintained as an independent project, but stable
 versions are distributed as part of the Git suite for the convenience
 of end users.</p>
-<p>A git-gui development repository can be obtained from:</p>
+<p>A <tt>git-gui</tt> development repository can be obtained from:</p>
 <div class="literalblock">
 <div class="content">
 <pre><tt>git clone git://repo.or.cz/git-gui.git</tt></pre>
@@ -433,7 +433,7 @@ of end users.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:45 UTC
+Last updated 02-Jul-2008 03:01:47 UTC
 </div>
 </div>
 </body>
diff --git a/git-gui.txt b/git-gui.txt
index 105397f2b..940e43f37 100644
--- a/git-gui.txt
+++ b/git-gui.txt
@@ -11,19 +11,19 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-A Tcl/Tk based graphical user interface to Git.  git-gui focuses
+A Tcl/Tk based graphical user interface to Git.  `git-gui` focuses
 on allowing users to make changes to their repository by making
 new commits, amending existing ones, creating branches, performing
 local merges, and fetching/pushing to remote repositories.
 
-Unlike linkgit:gitk[1], git-gui focuses on commit generation
-and single file annotation, and does not show project history.
-It does however supply menu actions to start a gitk session from
-within git-gui.
+Unlike `gitk`, `git-gui` focuses on commit generation
+and single file annotation and does not show project history.
+It does however supply menu actions to start a `gitk` session from
+within `git-gui`.
 
-git-gui is known to work on all popular UNIX systems, Mac OS X,
+`git-gui` is known to work on all popular UNIX systems, Mac OS X,
 and Windows (under both Cygwin and MSYS).  To the extent possible
-OS specific user interface guidelines are followed, making git-gui
+OS specific user interface guidelines are followed, making `git-gui`
 a fairly native interface for users.
 
 COMMANDS
@@ -38,13 +38,13 @@ browser::
 	browser are opened in the blame viewer.
 
 citool::
-	Start git-gui and arrange to make exactly one commit before
+	Start `git-gui` and arrange to make exactly one commit before
 	exiting and returning to the shell.  The interface is limited
 	to only commit actions, slightly reducing the application's
 	startup time and simplifying the menubar.
 
 version::
-	Display the currently running version of git-gui.
+	Display the currently running version of `git-gui`.
 
 
 Examples
@@ -84,15 +84,15 @@ SEE ALSO
 linkgit:gitk[1]::
 	The git repository browser.  Shows branches, commit history
 	and file differences.  gitk is the utility started by
-	git-gui's Repository Visualize actions.
+	`git-gui`'s Repository Visualize actions.
 
 Other
 -----
-git-gui is actually maintained as an independent project, but stable
+`git-gui` is actually maintained as an independent project, but stable
 versions are distributed as part of the Git suite for the convenience
 of end users.
 
-A git-gui development repository can be obtained from:
+A `git-gui` development repository can be obtained from:
 
   git clone git://repo.or.cz/git-gui.git
 
diff --git a/git-hash-object.html b/git-hash-object.html
index 1cdfb6d49..38273aee2 100644
--- a/git-hash-object.html
+++ b/git-hash-object.html
@@ -272,7 +272,7 @@ git-hash-object(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-hash-object</em> [-t &lt;type&gt;] [-w] [--stdin | --stdin-paths] [--] &lt;file&gt;&#8230;</p>
+<p><em>git hash-object</em> [-t &lt;type&gt;] [-w] [--stdin | --stdin-paths] [--] &lt;file&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -280,7 +280,7 @@ git-hash-object(1) Manual Page
 with the contents of the named file (which can be outside of the
 work tree), and optionally writes the resulting object into the
 object database.  Reports its object ID to its standard output.
-This is used by "git-cvsimport" to update the index
+This is used by <tt>git-cvsimport</tt> to update the index
 without modifying files in the work tree.  When &lt;type&gt; is not
 specified, it defaults to "blob".</p>
 </div>
@@ -335,7 +335,7 @@ specified, it defaults to "blob".</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:45 UTC
+Last updated 02-Jul-2008 03:01:48 UTC
 </div>
 </div>
 </body>
diff --git a/git-hash-object.txt b/git-hash-object.txt
index cf3dce8a4..05550c5ac 100644
--- a/git-hash-object.txt
+++ b/git-hash-object.txt
@@ -8,7 +8,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
 
 SYNOPSIS
 --------
-'git-hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
+'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
 
 DESCRIPTION
 -----------
@@ -16,7 +16,7 @@ Computes the object ID value for an object with specified type
 with the contents of the named file (which can be outside of the
 work tree), and optionally writes the resulting object into the
 object database.  Reports its object ID to its standard output.
-This is used by "git-cvsimport" to update the index
+This is used by `git-cvsimport` to update the index
 without modifying files in the work tree.  When <type> is not
 specified, it defaults to "blob".
 
diff --git a/git-help.html b/git-help.html
index f46269f6d..a0ca75eae 100644
--- a/git-help.html
+++ b/git-help.html
@@ -343,8 +343,8 @@ other display programs (see below).</p>
 </p>
 <p>The web browser can be specified using the configuration variable
 <em>help.browser</em>, or <em>web.browser</em> if the former is not set. If none of
-these config variables is set, the <em>git-web--browse</em> helper script
-(called by <em>git-help</em>) will pick a suitable default. See
+these config variables is set, the <tt>git-web--browse</tt> helper script
+(called by <tt>git-help</tt>) will pick a suitable default. See
 <a href="git-web--browse.html">git-web--browse(1)</a> for more information about this.</p>
 </dd>
 </dl>
@@ -354,7 +354,7 @@ these config variables is set, the <em>git-web--browse</em> helper script
 <h3>help.format</h3>
 <p>If no command line option is passed, the <em>help.format</em> configuration
 variable will be checked. The following values are supported for this
-variable; they make <em>git-help</em> behave as their corresponding command
+variable; they make <tt>git-help</tt> behave as their corresponding command
 line option:</p>
 <ul>
 <li>
@@ -473,7 +473,7 @@ little. Maintenance is done by the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:42 UTC
+Last updated 02-Jul-2008 03:01:48 UTC
 </div>
 </div>
 </body>
diff --git a/git-help.txt b/git-help.txt
index faecd6bb9..5ace863c1 100644
--- a/git-help.txt
+++ b/git-help.txt
@@ -55,8 +55,8 @@ other display programs (see below).
 +
 The web browser can be specified using the configuration variable
 'help.browser', or 'web.browser' if the former is not set. If none of
-these config variables is set, the 'git-web--browse' helper script
-(called by 'git-help') will pick a suitable default. See
+these config variables is set, the `git-web--browse` helper script
+(called by `git-help`) will pick a suitable default. See
 linkgit:git-web--browse[1] for more information about this.
 
 CONFIGURATION VARIABLES
@@ -67,7 +67,7 @@ help.format
 
 If no command line option is passed, the 'help.format' configuration
 variable will be checked. The following values are supported for this
-variable; they make 'git-help' behave as their corresponding command
+variable; they make `git-help` behave as their corresponding command
 line option:
 
 * "man" corresponds to '-m|--man',
diff --git a/git-http-fetch.html b/git-http-fetch.html
index afbb6194d..5ed9ef290 100644
--- a/git-http-fetch.html
+++ b/git-http-fetch.html
@@ -272,7 +272,7 @@ git-http-fetch(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-http-fetch</em> [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] &lt;commit&gt; &lt;url&gt;</p>
+<p><em>git http-fetch</em> [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] &lt;commit&gt; &lt;url&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -337,7 +337,7 @@ commit-id
 <dd>
 <p>
         Instead of a commit id on the command line (which is not expected in this
-        case), <em>git-http-fetch</em> expects lines on stdin in the format
+        case), <tt>git-http-fetch</tt> expects lines on stdin in the format
 </p>
 <div class="literalblock">
 <div class="content">
@@ -369,7 +369,7 @@ commit-id
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:46 UTC
+Last updated 02-Jul-2008 03:01:48 UTC
 </div>
 </div>
 </body>
diff --git a/git-http-fetch.txt b/git-http-fetch.txt
index 70fb63529..cfc5989b9 100644
--- a/git-http-fetch.txt
+++ b/git-http-fetch.txt
@@ -8,7 +8,7 @@ git-http-fetch - Download from a remote git repository via HTTP
 
 SYNOPSIS
 --------
-'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
+'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
 
 DESCRIPTION
 -----------
@@ -35,7 +35,7 @@ commit-id::
 
 --stdin::
 	Instead of a commit id on the command line (which is not expected in this
-	case), 'git-http-fetch' expects lines on stdin in the format
+	case), `git-http-fetch` expects lines on stdin in the format
 
 		<commit-id>['\t'<filename-as-in--w>]
 
diff --git a/git-http-push.html b/git-http-push.html
index 347af19fe..59a92067f 100644
--- a/git-http-push.html
+++ b/git-http-push.html
@@ -272,7 +272,7 @@ git-http-push(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-http-push</em> [--all] [--dry-run] [--force] [--verbose] &lt;url&gt; &lt;ref&gt; [&lt;ref&gt;&#8230;]</p>
+<p><em>git http-push</em> [--all] [--dry-run] [--force] [--verbose] &lt;url&gt; &lt;ref&gt; [&lt;ref&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -426,7 +426,7 @@ to disable the fast-forward check only on that ref.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 16-Jun-2008 01:52:17 UTC
+Last updated 02-Jul-2008 03:01:49 UTC
 </div>
 </div>
 </body>
diff --git a/git-http-push.txt b/git-http-push.txt
index d69b20549..aef383e0b 100644
--- a/git-http-push.txt
+++ b/git-http-push.txt
@@ -8,7 +8,7 @@ git-http-push - Push objects over HTTP/DAV to another repository
 
 SYNOPSIS
 --------
-'git-http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
+'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
 
 DESCRIPTION
 -----------
diff --git a/git-imap-send.html b/git-imap-send.html
index 911185f76..73fc27173 100644
--- a/git-imap-send.html
+++ b/git-imap-send.html
@@ -272,7 +272,7 @@ git-imap-send(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-imap-send</em></p>
+<p><em>git imap-send</em></p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,11 +281,11 @@ into an imap drafts folder.  This allows patches to be sent as
 other email is sent with mail clients that cannot read mailbox
 files directly.</p>
 <p>Typical usage is something like:</p>
-<p>git-format-patch --signoff --stdout --attach origin | git-imap-send</p>
+<p>git format-patch --signoff --stdout --attach origin | git imap-send</p>
 </div>
 <h2>CONFIGURATION</h2>
 <div class="sectionbody">
-<p>git-imap-send requires the following values in the repository
+<p><tt>git-imap-send</tt> requires the following values in the repository
 configuration file (shown with examples):</p>
 <div class="literalblock">
 <div class="content">
@@ -320,7 +320,7 @@ configuration file (shown with examples):</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:47 UTC
+Last updated 02-Jul-2008 03:01:49 UTC
 </div>
 </div>
 </body>
diff --git a/git-imap-send.txt b/git-imap-send.txt
index f4fdc2428..776aa254d 100644
--- a/git-imap-send.txt
+++ b/git-imap-send.txt
@@ -8,7 +8,7 @@ git-imap-send - Dump a mailbox from stdin into an imap folder
 
 SYNOPSIS
 --------
-'git-imap-send'
+'git imap-send'
 
 
 DESCRIPTION
@@ -20,13 +20,13 @@ files directly.
 
 Typical usage is something like:
 
-git-format-patch --signoff --stdout --attach origin | git-imap-send
+git format-patch --signoff --stdout --attach origin | git imap-send
 
 
 CONFIGURATION
 -------------
 
-git-imap-send requires the following values in the repository
+`git-imap-send` requires the following values in the repository
 configuration file (shown with examples):
 
 ..........................
diff --git a/git-index-pack.html b/git-index-pack.html
index a55afda5f..b80cfb46b 100644
--- a/git-index-pack.html
+++ b/git-index-pack.html
@@ -273,8 +273,8 @@ git-index-pack(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-index-pack</em> [-v] [-o &lt;index-file&gt;] &lt;pack-file&gt;
-<em>git-index-pack</em> --stdin [--fix-thin] [--keep] [-v] [-o &lt;index-file&gt;]
+<div class="content"><em>git index-pack</em> [-v] [-o &lt;index-file&gt;] &lt;pack-file&gt;
+<em>git index-pack</em> --stdin [--fix-thin] [--keep] [-v] [-o &lt;index-file&gt;]
                  [&lt;pack-file&gt;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -320,7 +320,7 @@ objects/pack/ directory of a git repository.</p>
         a default name determined from the pack content.  If
         &lt;pack-file&gt; is not specified consider using --keep to
         prevent a race condition between this process and
-        <a href="git-repack.html">git-repack(1)</a>.
+        <tt>git-repack</tt>.
 </p>
 </dd>
 <dt>
@@ -328,7 +328,7 @@ objects/pack/ directory of a git repository.</p>
 </dt>
 <dd>
 <p>
-        It is possible for <a href="git-pack-objects.html">git-pack-objects(1)</a> to build
+        It is possible for <tt>git-pack-objects</tt> to build
         "thin" pack, which records objects in deltified form based on
         objects not included in the pack to reduce network traffic.
         Those objects are expected to be present on the receiving end
@@ -346,7 +346,7 @@ objects/pack/ directory of a git repository.</p>
         Before moving the index into its final destination
         create an empty .keep file for the associated pack file.
         This option is usually necessary with --stdin to prevent a
-        simultaneous <a href="git-repack.html">git-repack(1)</a> process from deleting
+        simultaneous <tt>git-repack</tt> process from deleting
         the newly constructed pack and index before refs can be
         updated to use objects contained in the pack.
 </p>
@@ -389,7 +389,7 @@ objects/pack/ directory of a git repository.</p>
 and the SHA1 hash of that list is printed to stdout. If --stdin was
 also used then this is prefixed by either "pack\t", or "keep\t" if a
 new .keep file was successfully created. This is useful to remove a
-.keep file used as a lock to prevent the race with <a href="git-repack.html">git-repack(1)</a>
+.keep file used as a lock to prevent the race with <tt>git-repack</tt>
 mentioned above.</p>
 </div>
 <h2>Author</h2>
@@ -406,7 +406,7 @@ mentioned above.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:47 UTC
+Last updated 02-Jul-2008 03:01:49 UTC
 </div>
 </div>
 </body>
diff --git a/git-index-pack.txt b/git-index-pack.txt
index 6409363ae..194023774 100644
--- a/git-index-pack.txt
+++ b/git-index-pack.txt
@@ -9,8 +9,8 @@ git-index-pack - Build pack index file for an existing packed archive
 SYNOPSIS
 --------
 [verse]
-'git-index-pack' [-v] [-o <index-file>] <pack-file>
-'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
+'git index-pack' [-v] [-o <index-file>] <pack-file>
+'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
                  [<pack-file>]
 
 
@@ -43,10 +43,10 @@ OPTIONS
 	a default name determined from the pack content.  If
 	<pack-file> is not specified consider using --keep to
 	prevent a race condition between this process and
-	linkgit:git-repack[1].
+	`git-repack`.
 
 --fix-thin::
-	It is possible for linkgit:git-pack-objects[1] to build
+	It is possible for `git-pack-objects` to build
 	"thin" pack, which records objects in deltified form based on
 	objects not included in the pack to reduce network traffic.
 	Those objects are expected to be present on the receiving end
@@ -59,7 +59,7 @@ OPTIONS
 	Before moving the index into its final destination
 	create an empty .keep file for the associated pack file.
 	This option is usually necessary with --stdin to prevent a
-	simultaneous linkgit:git-repack[1] process from deleting
+	simultaneous `git-repack` process from deleting
 	the newly constructed pack and index before refs can be
 	updated to use objects contained in the pack.
 
@@ -86,7 +86,7 @@ Once the index has been created, the list of object names is sorted
 and the SHA1 hash of that list is printed to stdout. If --stdin was
 also used then this is prefixed by either "pack\t", or "keep\t" if a
 new .keep file was successfully created. This is useful to remove a
-.keep file used as a lock to prevent the race with linkgit:git-repack[1]
+.keep file used as a lock to prevent the race with `git-repack`
 mentioned above.
 
 
diff --git a/git-init-db.html b/git-init-db.html
index 5b83c31cb..647971619 100644
--- a/git-init-db.html
+++ b/git-init-db.html
@@ -272,7 +272,7 @@ git-init-db(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-init-db</em> [-q | --quiet] [--template=&lt;template_directory&gt;] [--shared[=&lt;permissions&gt;]]</p>
+<p><em>git init-db</em> [-q | --quiet] [--template=&lt;template_directory&gt;] [--shared[=&lt;permissions&gt;]]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,7 +281,7 @@ documentation of that command.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:47 UTC
+Last updated 02-Jul-2008 03:01:49 UTC
 </div>
 </div>
 </body>
diff --git a/git-init-db.txt b/git-init-db.txt
index 439cabb73..1fd0ff261 100644
--- a/git-init-db.txt
+++ b/git-init-db.txt
@@ -8,7 +8,7 @@ git-init-db - Creates an empty git repository
 
 SYNOPSIS
 --------
-'git-init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
 
 
 DESCRIPTION
diff --git a/git-init.html b/git-init.html
index 9540f5242..ccdb11773 100644
--- a/git-init.html
+++ b/git-init.html
@@ -272,7 +272,7 @@ git-init(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-init</em> [-q | --quiet] [--bare] [--template=&lt;template_directory&gt;] [--shared[=&lt;permissions&gt;]]</p>
+<p><em>git init</em> [-q | --quiet] [--bare] [--template=&lt;template_directory&gt;] [--shared[=&lt;permissions&gt;]]</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -392,8 +392,8 @@ Start a new git repository for an existing code base
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ cd /path/to/my/codebase
-$ git-init      <b>(1)</b>
-$ git-add .     <b>(2)</b></tt></pre>
+$ git init      <b>(1)</b>
+$ git add .     <b>(2)</b></tt></pre>
 </div></div>
 <ol>
 <li>
@@ -424,7 +424,7 @@ add all existing file to the index
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:43 UTC
+Last updated 02-Jul-2008 03:01:49 UTC
 </div>
 </div>
 </body>
diff --git a/git-init.txt b/git-init.txt
index 792643c80..45244737f 100644
--- a/git-init.txt
+++ b/git-init.txt
@@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one
 
 SYNOPSIS
 --------
-'git-init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
 
 
 OPTIONS
@@ -105,8 +105,8 @@ Start a new git repository for an existing code base::
 +
 ----------------
 $ cd /path/to/my/codebase
-$ git-init      <1>
-$ git-add .     <2>
+$ git init      <1>
+$ git add .     <2>
 ----------------
 +
 <1> prepare /path/to/my/codebase/.git directory
diff --git a/git-instaweb.html b/git-instaweb.html
index bb9bfd693..24b42b434 100644
--- a/git-instaweb.html
+++ b/git-instaweb.html
@@ -273,13 +273,13 @@ git-instaweb(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-instaweb</em> [--local] [--httpd=&lt;httpd&gt;] [--port=&lt;port&gt;]
+<div class="content"><em>git instaweb</em> [--local] [--httpd=&lt;httpd&gt;] [--port=&lt;port&gt;]
                [--browser=&lt;browser&gt;]
-<em>git-instaweb</em> [--start] [--stop] [--restart]</div></div>
+<em>git instaweb</em> [--start] [--stop] [--restart]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>A simple script to setup gitweb and a web server for browsing the local
+<p>A simple script to set up <tt>gitweb</tt> and a web server for browsing the local
 repository.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -343,7 +343,7 @@ repository.</p>
 <dd>
 <p>
         The web browser that should be used to view the gitweb
-        page. This will be passed to the <em>git-web--browse</em> helper
+        page. This will be passed to the <tt>git-web--browse</tt> helper
         script along with the URL of the gitweb instance. See
         <a href="git-web--browse.html">git-web--browse(1)</a> for more information about this. If
         the script fails, the URL will be printed to stdout.
@@ -410,7 +410,7 @@ repository.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:44 UTC
+Last updated 02-Jul-2008 03:01:50 UTC
 </div>
 </div>
 </body>
diff --git a/git-instaweb.txt b/git-instaweb.txt
index 7da5b8d9a..e7ca537e3 100644
--- a/git-instaweb.txt
+++ b/git-instaweb.txt
@@ -8,13 +8,13 @@ git-instaweb - Instantly browse your working repository in gitweb
 SYNOPSIS
 --------
 [verse]
-'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
+'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
                [--browser=<browser>]
-'git-instaweb' [--start] [--stop] [--restart]
+'git instaweb' [--start] [--stop] [--restart]
 
 DESCRIPTION
 -----------
-A simple script to setup gitweb and a web server for browsing the local
+A simple script to set up `gitweb` and a web server for browsing the local
 repository.
 
 OPTIONS
@@ -44,7 +44,7 @@ OPTIONS
 -b::
 --browser::
 	The web browser that should be used to view the gitweb
-	page. This will be passed to the 'git-web--browse' helper
+	page. This will be passed to the `git-web--browse` helper
 	script along with the URL of the gitweb instance. See
 	linkgit:git-web--browse[1] for more information about this. If
 	the script fails, the URL will be printed to stdout.
diff --git a/git-log.html b/git-log.html
index d5e83b836..030962c91 100644
--- a/git-log.html
+++ b/git-log.html
@@ -272,14 +272,14 @@ git-log(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-log</em> &lt;option&gt;&#8230;</p>
+<p><em>git log</em> &lt;option&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Shows the commit logs.</p>
-<p>The command takes options applicable to the <a href="git-rev-list.html">git-rev-list(1)</a>
+<p>The command takes options applicable to the <tt>git-rev-list</tt>
 command to control what is shown and how, and options applicable to
-the <a href="git-diff-tree.html">git-diff-tree(1)</a> commands to control how the changes
+the <tt>git-diff-*</tt> commands to control how the changes
 each commit introduces are shown.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -758,7 +758,7 @@ each commit introduces are shown.</p>
 </dd>
 </dl>
 <p>For more detailed explanation on these common options, see also
-<a href="gitdiffcore.html">gitdiffcore(7)</a>[diffcore documentation].</p>
+<a href="gitdiffcore.html">gitdiffcore(7)</a>.</p>
 <dl>
 <dt>
 -&lt;n&gt;
@@ -1964,7 +1964,7 @@ reversible operation.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:41 UTC
+Last updated 02-Jul-2008 03:01:50 UTC
 </div>
 </div>
 </body>
diff --git a/git-log.txt b/git-log.txt
index db61bc96c..3373c2636 100644
--- a/git-log.txt
+++ b/git-log.txt
@@ -8,15 +8,15 @@ git-log - Show commit logs
 
 SYNOPSIS
 --------
-'git-log' <option>...
+'git log' <option>...
 
 DESCRIPTION
 -----------
 Shows the commit logs.
 
-The command takes options applicable to the linkgit:git-rev-list[1]
+The command takes options applicable to the `git-rev-list`
 command to control what is shown and how, and options applicable to
-the linkgit:git-diff-tree[1] commands to control how the changes
+the `git-diff-*` commands to control how the changes
 each commit introduces are shown.
 
 
diff --git a/git-lost-found.html b/git-lost-found.html
index 73a5e23f3..eac835d08 100644
--- a/git-lost-found.html
+++ b/git-lost-found.html
@@ -272,7 +272,7 @@ git-lost-found(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-lost-found</em></p>
+<p><em>git lost-found</em></p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -340,7 +340,7 @@ $ git rev-parse not-lost-anymore
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:49 UTC
+Last updated 02-Jul-2008 03:01:50 UTC
 </div>
 </div>
 </body>
diff --git a/git-lost-found.txt b/git-lost-found.txt
index 4dc475e0d..602b8d5d4 100644
--- a/git-lost-found.txt
+++ b/git-lost-found.txt
@@ -7,7 +7,7 @@ git-lost-found - Recover lost refs that luckily have not yet been pruned
 
 SYNOPSIS
 --------
-'git-lost-found'
+'git lost-found'
 
 DESCRIPTION
 -----------
diff --git a/git-ls-files.html b/git-ls-files.html
index 0c873b868..7cb7be093 100644
--- a/git-ls-files.html
+++ b/git-ls-files.html
@@ -273,7 +273,7 @@ git-ls-files(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-ls-files</em> [-z] [-t] [-v]
+<div class="content"><em>git ls-files</em> [-z] [-t] [-v]
                 (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
                 (-[c|d|o|i|s|u|k|m])*
                 [-x &lt;pattern&gt;|--exclude=&lt;pattern&gt;]
@@ -589,20 +589,20 @@ which case it outputs:</p>
 <div class="content">
 <pre><tt>[&lt;tag&gt; ]&lt;mode&gt; &lt;object&gt; &lt;stage&gt; &lt;file&gt;</tt></pre>
 </div></div>
-<p>"git-ls-files --unmerged" and "git-ls-files --stage" can be used to examine
+<p><tt>git-ls-files --unmerged</tt> and <tt>git-ls-files --stage</tt> can be used to examine
 detailed information on unmerged paths.</p>
 <p>For an unmerged path, instead of recording a single mode/SHA1 pair,
 the index records up to three such pairs; one from tree O in stage
 1, A in stage 2, and B in stage 3.  This information can be used by
 the user (or the porcelain) to see what should eventually be recorded at the
-path. (see git-read-tree for more information on state)</p>
+path. (see <a href="git-read-tree.html">git-read-tree(1)</a> for more information on state)</p>
 <p>When <tt>-z</tt> option is not used, TAB, LF, and backslash characters
 in pathnames are represented as <tt>\t</tt>, <tt>\n</tt>, and <tt>\\</tt>,
 respectively.</p>
 </div>
 <h2>Exclude Patterns</h2>
 <div class="sectionbody">
-<p><em>git-ls-files</em> can use a list of "exclude patterns" when
+<p><tt>git-ls-files</tt> can use a list of "exclude patterns" when
 traversing the directory tree and finding files to show when the
 flags --others or --ignored are specified.  <a href="gitignore.html">gitignore(5)</a>
 specifies the format of exclude patterns.</p>
@@ -625,7 +625,7 @@ The command line flag --exclude-from=&lt;file&gt; specifies a
 <li>
 <p>
 command line flag --exclude-per-directory=&lt;name&gt; specifies
-     a name of the file in each directory <em>git-ls-files</em>
+     a name of the file in each directory <tt>git-ls-files</tt>
      examines, normally <tt>.gitignore</tt>.  Files in deeper
      directories take precedence.  Patterns are ordered in the
      same order they appear in the files.
@@ -656,7 +656,7 @@ pattern file appears in.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:45 UTC
+Last updated 02-Jul-2008 03:01:50 UTC
 </div>
 </div>
 </body>
diff --git a/git-ls-files.txt b/git-ls-files.txt
index 560594e25..a6883bf43 100644
--- a/git-ls-files.txt
+++ b/git-ls-files.txt
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
 SYNOPSIS
 --------
 [verse]
-'git-ls-files' [-z] [-t] [-v]
+'git ls-files' [-z] [-t] [-v]
 		(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
 		(-[c|d|o|i|s|u|k|m])\*
 		[-x <pattern>|--exclude=<pattern>]
@@ -143,14 +143,14 @@ which case it outputs:
 
         [<tag> ]<mode> <object> <stage> <file>
 
-"git-ls-files --unmerged" and "git-ls-files --stage" can be used to examine
+`git-ls-files --unmerged` and `git-ls-files --stage` can be used to examine
 detailed information on unmerged paths.
 
 For an unmerged path, instead of recording a single mode/SHA1 pair,
 the index records up to three such pairs; one from tree O in stage
 1, A in stage 2, and B in stage 3.  This information can be used by
 the user (or the porcelain) to see what should eventually be recorded at the
-path. (see git-read-tree for more information on state)
+path. (see linkgit:git-read-tree[1] for more information on state)
 
 When `-z` option is not used, TAB, LF, and backslash characters
 in pathnames are represented as `\t`, `\n`, and `\\`,
@@ -160,7 +160,7 @@ respectively.
 Exclude Patterns
 ----------------
 
-'git-ls-files' can use a list of "exclude patterns" when
+`git-ls-files` can use a list of "exclude patterns" when
 traversing the directory tree and finding files to show when the
 flags --others or --ignored are specified.  linkgit:gitignore[5]
 specifies the format of exclude patterns.
@@ -176,7 +176,7 @@ These exclude patterns come from these places, in order:
      in the same order they appear in the file.
 
   3. command line flag --exclude-per-directory=<name> specifies
-     a name of the file in each directory 'git-ls-files'
+     a name of the file in each directory `git-ls-files`
      examines, normally `.gitignore`.  Files in deeper
      directories take precedence.  Patterns are ordered in the
      same order they appear in the files.
diff --git a/git-ls-remote.html b/git-ls-remote.html
index 5253d8dea..731a8909f 100644
--- a/git-ls-remote.html
+++ b/git-ls-remote.html
@@ -273,7 +273,7 @@ git-ls-remote(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-ls-remote</em> [--heads] [--tags]  [-u &lt;exec&gt; | --upload-pack &lt;exec&gt;]
+<div class="content"><em>git ls-remote</em> [--heads] [--tags]  [-u &lt;exec&gt; | --upload-pack &lt;exec&gt;]
               &lt;repository&gt; &lt;refs&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -312,7 +312,7 @@ commit IDs.</p>
 </dt>
 <dd>
 <p>
-        Specify the full path of <a href="git-upload-pack.html">git-upload-pack(1)</a> on the remote
+        Specify the full path of <tt>git-upload-pack</tt> on the remote
         host. This allows listing references from repositories accessed via
         SSH and where the SSH daemon does not use the PATH configured by the
         user.
@@ -373,7 +373,7 @@ c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:47 UTC
+Last updated 02-Jul-2008 03:01:51 UTC
 </div>
 </div>
 </body>
diff --git a/git-ls-remote.txt b/git-ls-remote.txt
index f92f3ca18..c267cdae4 100644
--- a/git-ls-remote.txt
+++ b/git-ls-remote.txt
@@ -9,7 +9,7 @@ git-ls-remote - List references in a remote repository
 SYNOPSIS
 --------
 [verse]
-'git-ls-remote' [--heads] [--tags]  [-u <exec> | --upload-pack <exec>]
+'git ls-remote' [--heads] [--tags]  [-u <exec> | --upload-pack <exec>]
 	      <repository> <refs>...
 
 DESCRIPTION
@@ -31,7 +31,7 @@ OPTIONS
 
 -u <exec>::
 --upload-pack=<exec>::
-	Specify the full path of linkgit:git-upload-pack[1] on the remote
+	Specify the full path of `git-upload-pack` on the remote
 	host. This allows listing references from repositories accessed via
 	SSH and where the SSH daemon does not use the PATH configured by the
 	user.
diff --git a/git-ls-tree.html b/git-ls-tree.html
index 3373f9254..b98d019ee 100644
--- a/git-ls-tree.html
+++ b/git-ls-tree.html
@@ -273,7 +273,7 @@ git-ls-tree(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-ls-tree</em> [-d] [-r] [-t] [-l] [-z]
+<div class="content"><em>git ls-tree</em> [-d] [-r] [-t] [-l] [-z]
             [--name-only] [--name-status] [--full-name] [--abbrev=[&lt;n&gt;]]
             &lt;tree-ish&gt; [paths&#8230;]</div></div>
 </div>
@@ -416,7 +416,7 @@ another major rewrite by Linus Torvalds &lt;torvalds@osdl.org&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:51 UTC
+Last updated 02-Jul-2008 03:01:51 UTC
 </div>
 </div>
 </body>
diff --git a/git-ls-tree.txt b/git-ls-tree.txt
index d9881fbbb..1cdec222a 100644
--- a/git-ls-tree.txt
+++ b/git-ls-tree.txt
@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object
 SYNOPSIS
 --------
 [verse]
-'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
+'git ls-tree' [-d] [-r] [-t] [-l] [-z]
 	    [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
 	    <tree-ish> [paths...]
 
diff --git a/git-mailinfo.html b/git-mailinfo.html
index b6a9a45ed..6a61a955b 100644
--- a/git-mailinfo.html
+++ b/git-mailinfo.html
@@ -272,14 +272,14 @@ git-mailinfo(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mailinfo</em> [-k] [-u | --encoding=&lt;encoding&gt;] &lt;msg&gt; &lt;patch&gt;</p>
+<p><em>git mailinfo</em> [-k] [-u | --encoding=&lt;encoding&gt;] &lt;msg&gt; &lt;patch&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Reading a single e-mail message from the standard input, and
 writes the commit log message in &lt;msg&gt; file, and the patches in
 &lt;patch&gt; file.  The author name, e-mail and e-mail subject are
-written out to the standard output to be used by git-am
+written out to the standard output to be used by <tt>git-am</tt>
 to create a commit.  It is usually not necessary to use this
 command directly.  See <a href="git-am.html">git-am(1)</a> instead.</p>
 </div>
@@ -296,8 +296,8 @@ command directly.  See <a href="git-am.html">git-am(1)</a> instead.</p>
         among which (1) remove <em>Re:</em> or <em>re:</em>, (2) leading
         whitespaces, (3) <em>[</em> up to <em>]</em>, typically <em>[PATCH]</em>, and
         then prepends "[PATCH] ".  This flag forbids this
-        munging, and is most useful when used to read back <em>git
-        format-patch -k</em> output.
+        munging, and is most useful when used to read back
+        <tt>git-format-patch -k</tt> output.
 </p>
 </dd>
 <dt>
@@ -357,7 +357,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:52 UTC
+Last updated 02-Jul-2008 03:01:52 UTC
 </div>
 </div>
 </body>
diff --git a/git-mailinfo.txt b/git-mailinfo.txt
index 183dc1dd7..6ebdeee84 100644
--- a/git-mailinfo.txt
+++ b/git-mailinfo.txt
@@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
 
 SYNOPSIS
 --------
-'git-mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
+'git mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
 
 
 DESCRIPTION
@@ -16,7 +16,7 @@ DESCRIPTION
 Reading a single e-mail message from the standard input, and
 writes the commit log message in <msg> file, and the patches in
 <patch> file.  The author name, e-mail and e-mail subject are
-written out to the standard output to be used by git-am
+written out to the standard output to be used by `git-am`
 to create a commit.  It is usually not necessary to use this
 command directly.  See linkgit:git-am[1] instead.
 
@@ -29,8 +29,8 @@ OPTIONS
 	among which (1) remove 'Re:' or 're:', (2) leading
 	whitespaces, (3) '[' up to ']', typically '[PATCH]', and
 	then prepends "[PATCH] ".  This flag forbids this
-	munging, and is most useful when used to read back 'git
-	format-patch -k' output.
+	munging, and is most useful when used to read back
+	`git-format-patch -k` output.
 
 -u::
 	The commit log message, author name and author email are
diff --git a/git-mailsplit.html b/git-mailsplit.html
index 8ff3a87e5..ababbb95a 100644
--- a/git-mailsplit.html
+++ b/git-mailsplit.html
@@ -272,7 +272,7 @@ git-mailsplit(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mailsplit</em> [-b] [-f&lt;nn&gt;] [-d&lt;prec&gt;] -o&lt;directory&gt; [--] [&lt;mbox&gt;|&lt;Maildir&gt;&#8230;]</p>
+<p><em>git mailsplit</em> [-b] [-f&lt;nn&gt;] [-d&lt;prec&gt;] -o&lt;directory&gt; [--] [&lt;mbox&gt;|&lt;Maildir&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -362,7 +362,7 @@ and Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:52 UTC
+Last updated 02-Jul-2008 03:01:52 UTC
 </div>
 </div>
 </body>
diff --git a/git-mailsplit.txt b/git-mailsplit.txt
index 9a2aedd48..acd712b1c 100644
--- a/git-mailsplit.txt
+++ b/git-mailsplit.txt
@@ -7,7 +7,7 @@ git-mailsplit - Simple UNIX mbox splitter program
 
 SYNOPSIS
 --------
-'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
+'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
 
 DESCRIPTION
 -----------
diff --git a/git-merge-base.html b/git-merge-base.html
index 1723713dd..9c7cc1d48 100644
--- a/git-merge-base.html
+++ b/git-merge-base.html
@@ -272,17 +272,17 @@ git-merge-base(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-merge-base</em> [--all] &lt;commit&gt; &lt;commit&gt;</p>
+<p><em>git merge-base</em> [--all] &lt;commit&gt; &lt;commit&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>"git-merge-base" finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B <em>git-merge-base A
-B</em> will output a commit which is reachable from both A and B through
+<p><tt>git-merge-base</tt> finds as good a common ancestor as possible between
+the two commits. That is, given two commits A and B, <tt>git merge-base A
+B</tt> will output a commit which is reachable from both A and B through
 the parent relationship.</p>
 <p>Given a selection of equally good common ancestors it should not be
 relied on to decide in any particular way.</p>
-<p>The "git-merge-base" algorithm is still in flux - use the source&#8230;</p>
+<p>The <tt>git-merge-base</tt> algorithm is still in flux - use the source&#8230;</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -312,7 +312,7 @@ relied on to decide in any particular way.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:52 UTC
+Last updated 02-Jul-2008 03:01:52 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge-base.txt b/git-merge-base.txt
index bbe851239..41fb0c76a 100644
--- a/git-merge-base.txt
+++ b/git-merge-base.txt
@@ -8,20 +8,20 @@ git-merge-base - Find as good common ancestors as possible for a merge
 
 SYNOPSIS
 --------
-'git-merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>
 
 DESCRIPTION
 -----------
 
-"git-merge-base" finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B 'git-merge-base A
-B' will output a commit which is reachable from both A and B through
+`git-merge-base` finds as good a common ancestor as possible between
+the two commits. That is, given two commits A and B, `git merge-base A
+B` will output a commit which is reachable from both A and B through
 the parent relationship.
 
 Given a selection of equally good common ancestors it should not be
 relied on to decide in any particular way.
 
-The "git-merge-base" algorithm is still in flux - use the source...
+The `git-merge-base` algorithm is still in flux - use the source...
 
 OPTIONS
 -------
diff --git a/git-merge-file.html b/git-merge-file.html
index 1d457cdaf..d44d79295 100644
--- a/git-merge-file.html
+++ b/git-merge-file.html
@@ -273,19 +273,19 @@ git-merge-file(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-merge-file</em> [-L &lt;current-name&gt; [-L &lt;base-name&gt; [-L &lt;other-name&gt;]]]
+<div class="content"><em>git merge-file</em> [-L &lt;current-name&gt; [-L &lt;base-name&gt; [-L &lt;other-name&gt;]]]
         [-p|--stdout] [-q|--quiet] &lt;current-file&gt; &lt;base-file&gt; &lt;other-file&gt;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>git-file-merge incorporates all changes that lead from the <tt>&lt;base-file&gt;</tt>
+<p><tt>git-file-merge</tt> incorporates all changes that lead from the <tt>&lt;base-file&gt;</tt>
 to <tt>&lt;other-file&gt;</tt> into <tt>&lt;current-file&gt;</tt>. The result ordinarily goes into
-<tt>&lt;current-file&gt;</tt>. git-merge-file is useful for combining separate changes
+<tt>&lt;current-file&gt;</tt>. <tt>git-merge-file</tt> is useful for combining separate changes
 to an original. Suppose <tt>&lt;base-file&gt;</tt> is the original, and both
 <tt>&lt;current-file&gt;</tt> and <tt>&lt;other-file&gt;</tt> are modifications of <tt>&lt;base-file&gt;</tt>.
-Then git-merge-file combines both changes.</p>
+Then <tt>git-merge-file</tt> combines both changes.</p>
 <p>A conflict occurs if both <tt>&lt;current-file&gt;</tt> and <tt>&lt;other-file&gt;</tt> have changes
-in a common segment of lines. If a conflict is found, git-merge-file
+in a common segment of lines. If a conflict is found, <tt>git-merge-file</tt>
 normally outputs a warning and brackets the conflict with &lt;&lt;&lt;&lt;&lt;&lt;&lt; and
 &gt;&gt;&gt;&gt;&gt;&gt;&gt; lines. A typical conflict will look like this:</p>
 <div class="literalblock">
@@ -300,7 +300,7 @@ lines in file B
 the alternatives.</p>
 <p>The exit value of this program is negative on error, and the number of
 conflicts otherwise. If the merge was clean, the exit value is 0.</p>
-<p>git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+<p><tt>git-merge-file</tt> is designed to be a minimal clone of RCS <tt>merge</tt>; that is, it
 implements all of RCS merge's functionality which is needed by
 <a href="git.html">git(1)</a>.</p>
 </div>
@@ -315,7 +315,7 @@ implements all of RCS merge's functionality which is needed by
         This option may be given up to three times, and
         specifies labels to be used in place of the
         corresponding file names in conflict reports. That is,
-        <tt>git-merge-file -L x -L y -L z a b c</tt> generates output that
+        <tt>git merge-file -L x -L y -L z a b c</tt> generates output that
         looks like it came from files x, y and z instead of
         from files a, b and c.
 </p>
@@ -377,7 +377,7 @@ with parts copied from the original documentation of RCS merge.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:53 UTC
+Last updated 02-Jul-2008 03:01:52 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge-file.txt b/git-merge-file.txt
index 149f13105..f057e4995 100644
--- a/git-merge-file.txt
+++ b/git-merge-file.txt
@@ -9,21 +9,21 @@ git-merge-file - Run a three-way file merge
 SYNOPSIS
 --------
 [verse]
-'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
+'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
 	[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
 
 
 DESCRIPTION
 -----------
-git-file-merge incorporates all changes that lead from the `<base-file>`
+`git-file-merge` incorporates all changes that lead from the `<base-file>`
 to `<other-file>` into `<current-file>`. The result ordinarily goes into
-`<current-file>`. git-merge-file is useful for combining separate changes
+`<current-file>`. `git-merge-file` is useful for combining separate changes
 to an original. Suppose `<base-file>` is the original, and both
 `<current-file>` and `<other-file>` are modifications of `<base-file>`.
-Then git-merge-file combines both changes.
+Then `git-merge-file` combines both changes.
 
 A conflict occurs if both `<current-file>` and `<other-file>` have changes
-in a common segment of lines. If a conflict is found, git-merge-file
+in a common segment of lines. If a conflict is found, `git-merge-file`
 normally outputs a warning and brackets the conflict with <<<<<<< and
 >>>>>>> lines. A typical conflict will look like this:
 
@@ -39,7 +39,7 @@ the alternatives.
 The exit value of this program is negative on error, and the number of
 conflicts otherwise. If the merge was clean, the exit value is 0.
 
-git-merge-file is designed to be a minimal clone of RCS merge, that is, it
+`git-merge-file` is designed to be a minimal clone of RCS `merge`; that is, it
 implements all of RCS merge's functionality which is needed by
 linkgit:git[1].
 
@@ -51,7 +51,7 @@ OPTIONS
 	This option may be given up to three times, and
 	specifies labels to be used in place of the
 	corresponding file names in conflict reports. That is,
-	`git-merge-file -L x -L y -L z a b c` generates output that
+	`git merge-file -L x -L y -L z a b c` generates output that
 	looks like it came from files x, y and z instead of
 	from files a, b and c.
 
diff --git a/git-merge-index.html b/git-merge-index.html
index 8d1b15146..5c5e0f9d5 100644
--- a/git-merge-index.html
+++ b/git-merge-index.html
@@ -272,7 +272,7 @@ git-merge-index(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-merge-index</em> [-o] [-q] &lt;merge-program&gt; (-a | [--] &lt;file&gt;*)</p>
+<p><em>git merge-index</em> [-o] [-q] &lt;merge-program&gt; (-a | [--] &lt;file&gt;*)</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -322,21 +322,21 @@ files are passed as arguments 5, 6 and 7.</p>
 </p>
 </dd>
 </dl>
-<p>If "git-merge-index" is called with multiple &lt;file&gt;s (or -a) then it
+<p>If <tt>git-merge-index</tt> is called with multiple &lt;file&gt;s (or -a) then it
 processes them in turn only stopping if merge returns a non-zero exit
 code.</p>
 <p>Typically this is run with a script calling git's imitation of
 the merge command from the RCS package.</p>
-<p>A sample script called "git-merge-one-file" is included in the
+<p>A sample script called <tt>git-merge-one-file</tt> is included in the
 distribution.</p>
 <p>ALERT ALERT ALERT! The git "merge object order" is different from the
-RCS "merge" program merge object order. In the above ordering, the
+RCS <tt>merge</tt> program merge object order. In the above ordering, the
 original is first. But the argument order to the 3-way merge program
-"merge" is to have the original in the middle. Don't ask me why.</p>
+<tt>merge</tt> is to have the original in the middle. Don't ask me why.</p>
 <p>Examples:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>torvalds@ppc970:~/merge-test&gt; git-merge-index cat MM
+<pre><tt>torvalds@ppc970:~/merge-test&gt; git merge-index cat MM
 This is MM from the original tree.                    # original
 This is modified MM in the branch A.                  # merge1
 This is modified MM in the branch B.                  # merge2
@@ -345,17 +345,17 @@ This is modified MM in the branch B.                  # current contents</tt></p
 <p>or</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>torvalds@ppc970:~/merge-test&gt; git-merge-index cat AA MM
+<pre><tt>torvalds@ppc970:~/merge-test&gt; git merge-index cat AA MM
 cat: : No such file or directory
 This is added AA in the branch A.
 This is added AA in the branch B.
 This is added AA in the branch B.
 fatal: merge program failed</tt></pre>
 </div></div>
-<p>where the latter example shows how "git-merge-index" will stop trying to
-merge once anything has returned an error (i.e., "cat" returned an error
+<p>where the latter example shows how <tt>git-merge-index</tt> will stop trying to
+merge once anything has returned an error (i.e., <tt>cat</tt> returned an error
 for the AA file, because it didn't exist in the original, and thus
-"git-merge-index" didn't even try to merge the MM thing).</p>
+<tt>git-merge-index</tt> didn't even try to merge the MM thing).</p>
 </div>
 <h2>Author</h2>
 <div class="sectionbody">
@@ -372,7 +372,7 @@ One-shot merge by Petr Baudis &lt;pasky@ucw.cz&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:53 UTC
+Last updated 02-Jul-2008 03:01:53 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge-index.txt b/git-merge-index.txt
index a0ead2bbf..43680840e 100644
--- a/git-merge-index.txt
+++ b/git-merge-index.txt
@@ -8,7 +8,7 @@ git-merge-index - Run a merge for files needing merging
 
 SYNOPSIS
 --------
-'git-merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
+'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
 
 DESCRIPTION
 -----------
@@ -36,24 +36,24 @@ OPTIONS
 	failure usually indicates conflicts during merge). This is for
 	porcelains which might want to emit custom messages.
 
-If "git-merge-index" is called with multiple <file>s (or -a) then it
+If `git-merge-index` is called with multiple <file>s (or -a) then it
 processes them in turn only stopping if merge returns a non-zero exit
 code.
 
 Typically this is run with a script calling git's imitation of
 the merge command from the RCS package.
 
-A sample script called "git-merge-one-file" is included in the
+A sample script called `git-merge-one-file` is included in the
 distribution.
 
 ALERT ALERT ALERT! The git "merge object order" is different from the
-RCS "merge" program merge object order. In the above ordering, the
+RCS `merge` program merge object order. In the above ordering, the
 original is first. But the argument order to the 3-way merge program
-"merge" is to have the original in the middle. Don't ask me why.
+`merge` is to have the original in the middle. Don't ask me why.
 
 Examples:
 
-  torvalds@ppc970:~/merge-test> git-merge-index cat MM
+  torvalds@ppc970:~/merge-test> git merge-index cat MM
   This is MM from the original tree.			# original
   This is modified MM in the branch A.			# merge1
   This is modified MM in the branch B.			# merge2
@@ -61,17 +61,17 @@ Examples:
 
 or
 
-  torvalds@ppc970:~/merge-test> git-merge-index cat AA MM
+  torvalds@ppc970:~/merge-test> git merge-index cat AA MM
   cat: : No such file or directory
   This is added AA in the branch A.
   This is added AA in the branch B.
   This is added AA in the branch B.
   fatal: merge program failed
 
-where the latter example shows how "git-merge-index" will stop trying to
-merge once anything has returned an error (i.e., "cat" returned an error
+where the latter example shows how `git-merge-index` will stop trying to
+merge once anything has returned an error (i.e., `cat` returned an error
 for the AA file, because it didn't exist in the original, and thus
-"git-merge-index" didn't even try to merge the MM thing).
+`git-merge-index` didn't even try to merge the MM thing).
 
 Author
 ------
diff --git a/git-merge-one-file.html b/git-merge-one-file.html
index 1ebb06171..03bcedfd2 100644
--- a/git-merge-one-file.html
+++ b/git-merge-one-file.html
@@ -276,8 +276,8 @@ git-merge-one-file(1) Manual Page
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>This is the standard helper program to use with "git-merge-index"
-to resolve a merge after the trivial merge done with "git-read-tree -m".</p>
+<p>This is the standard helper program to use with <tt>git-merge-index</tt>
+to resolve a merge after the trivial merge done with <tt>git-read-tree -m</tt>.</p>
 </div>
 <h2>Author</h2>
 <div class="sectionbody">
@@ -294,7 +294,7 @@ Junio C Hamano &lt;junkio@cox.net&gt; and Petr Baudis &lt;pasky@suse.cz&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:54 UTC
+Last updated 02-Jul-2008 03:01:53 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge-one-file.txt b/git-merge-one-file.txt
index 5c9ce641e..62e09afe1 100644
--- a/git-merge-one-file.txt
+++ b/git-merge-one-file.txt
@@ -12,8 +12,8 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-This is the standard helper program to use with "git-merge-index"
-to resolve a merge after the trivial merge done with "git-read-tree -m".
+This is the standard helper program to use with `git-merge-index`
+to resolve a merge after the trivial merge done with `git-read-tree -m`.
 
 Author
 ------
diff --git a/git-merge-tree.html b/git-merge-tree.html
index e90a53b5a..cb280941d 100644
--- a/git-merge-tree.html
+++ b/git-merge-tree.html
@@ -272,7 +272,7 @@ git-merge-tree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-merge-tree</em> &lt;base-tree&gt; &lt;branch1&gt; &lt;branch2&gt;</p>
+<p><em>git merge-tree</em> &lt;base-tree&gt; &lt;branch1&gt; &lt;branch2&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -300,7 +300,7 @@ entries that match &lt;branch1&gt; tree.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:54 UTC
+Last updated 02-Jul-2008 03:01:53 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge-tree.txt b/git-merge-tree.txt
index b785e0f6e..dbb0c1866 100644
--- a/git-merge-tree.txt
+++ b/git-merge-tree.txt
@@ -8,7 +8,7 @@ git-merge-tree - Show three-way merge without touching index
 
 SYNOPSIS
 --------
-'git-merge-tree' <base-tree> <branch1> <branch2>
+'git merge-tree' <base-tree> <branch1> <branch2>
 
 DESCRIPTION
 -----------
diff --git a/git-merge.html b/git-merge.html
index 68420e3db..12b4a4c83 100644
--- a/git-merge.html
+++ b/git-merge.html
@@ -273,9 +273,9 @@ git-merge(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-merge</em> [-n] [--stat] [--no-commit] [--squash] [-s &lt;strategy&gt;]&#8230;
+<div class="content"><em>git merge</em> [-n] [--stat] [--no-commit] [--squash] [-s &lt;strategy&gt;]&#8230;
         [-m &lt;msg&gt;] &lt;remote&gt; &lt;remote&gt;&#8230;
-<em>git-merge</em> &lt;msg&gt; HEAD &lt;remote&gt;&#8230;</div></div>
+<em>git merge</em> &lt;msg&gt; HEAD &lt;remote&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -507,8 +507,7 @@ subtree
 </dd>
 </dl>
 <p>If you tried a merge which resulted in a complex conflicts and
-would want to start over, you can recover with
-<a href="git-reset.html">git-reset(1)</a>.</p>
+would want to start over, you can recover with <tt>git-reset</tt>.</p>
 </div>
 <h2>CONFIGURATION</h2>
 <div class="sectionbody">
@@ -600,7 +599,7 @@ branch.&lt;name&gt;.mergeoptions
 <dd>
 <p>
         Sets default options for merging into branch &lt;name&gt;. The syntax and
-        supported options are equal to that of git-merge, but option values
+        supported options are equal to that of <tt>git-merge</tt>, but option values
         containing whitespace characters are currently not supported.
 </p>
 </dd>
@@ -612,7 +611,7 @@ branch.&lt;name&gt;.mergeoptions
 commits (usually, branch head or tag), and the index file must
 exactly match the
 tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit) when
-it happens.  In other words, <tt>git-diff --cached HEAD</tt> must
+it happens.  In other words, <tt>git diff --cached HEAD</tt> must
 report no changes.</p>
 <div class="admonitionblock">
 <table><tr>
@@ -704,7 +703,7 @@ Cleanly merged paths are updated both in the index file and
 For conflicting paths, the index file records up to three
    versions; stage1 stores the version from the common ancestor,
    stage2 from <tt>HEAD</tt>, and stage3 from the remote branch (you
-   can inspect the stages with <tt>git-ls-files -u</tt>).  The working
+   can inspect the stages with <tt>git ls-files -u</tt>).  The working
    tree files have the result of "merge" program; i.e. 3-way
    merge result with familiar conflict markers <tt>&lt;&lt;&lt; === &gt;&gt;&gt;</tt>.
 </p>
@@ -730,8 +729,8 @@ Decide not to merge.  The only clean-up you need are to reset
 </li>
 <li>
 <p>
-Resolve the conflicts.  <tt>git-diff</tt> would report only the
-   conflicting paths because of the above 2. and 3..  Edit the
+Resolve the conflicts.  <tt>git diff</tt> would report only the
+   conflicting paths because of the above 2. and 3.  Edit the
    working tree files into a desirable shape, <tt>git-add</tt> or <tt>git-rm</tt>
    them, to make the index file contain what the merge result
    should be, and run <tt>git-commit</tt> to commit the result.
@@ -742,7 +741,11 @@ Resolve the conflicts.  <tt>git-diff</tt> would report only the
 <h2>SEE ALSO</h2>
 <div class="sectionbody">
 <p><a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>, <a href="git-pull.html">git-pull(1)</a>,
-<a href="gitattributes.html">gitattributes(5)</a></p>
+<a href="gitattributes.html">gitattributes(5)</a>,
+<a href="git-reset.html">git-reset(1)</a>,
+<a href="git-diff.html">git-diff(1)</a>, <a href="git-ls-files.html">git-ls-files(1)</a>,
+<a href="git-add.html">git-add(1)</a>, <a href="git-rm.html">git-rm(1)</a>,
+<a href="git-mergetool.html">git-mergetool(1)</a></p>
 </div>
 <h2>Author</h2>
 <div class="sectionbody">
@@ -758,7 +761,7 @@ Resolve the conflicts.  <tt>git-diff</tt> would report only the
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:48 UTC
+Last updated 02-Jul-2008 03:01:53 UTC
 </div>
 </div>
 </body>
diff --git a/git-merge.txt b/git-merge.txt
index 55bc36747..e6fa2b9ae 100644
--- a/git-merge.txt
+++ b/git-merge.txt
@@ -9,9 +9,9 @@ git-merge - Join two or more development histories together
 SYNOPSIS
 --------
 [verse]
-'git-merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
+'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
 	[-m <msg>] <remote> <remote>...
-'git-merge' <msg> HEAD <remote>...
+'git merge' <msg> HEAD <remote>...
 
 DESCRIPTION
 -----------
@@ -41,8 +41,7 @@ include::merge-strategies.txt[]
 
 
 If you tried a merge which resulted in a complex conflicts and
-would want to start over, you can recover with
-linkgit:git-reset[1].
+would want to start over, you can recover with `git-reset`.
 
 CONFIGURATION
 -------------
@@ -50,7 +49,7 @@ include::merge-config.txt[]
 
 branch.<name>.mergeoptions::
 	Sets default options for merging into branch <name>. The syntax and
-	supported options are equal to that of git-merge, but option values
+	supported options are equal to that of `git-merge`, but option values
 	containing whitespace characters are currently not supported.
 
 HOW MERGE WORKS
@@ -60,7 +59,7 @@ A merge is always between the current `HEAD` and one or more
 commits (usually, branch head or tag), and the index file must
 exactly match the
 tree of `HEAD` commit (i.e. the contents of the last commit) when
-it happens.  In other words, `git-diff --cached HEAD` must
+it happens.  In other words, `git diff --cached HEAD` must
 report no changes.
 
 [NOTE]
@@ -128,7 +127,7 @@ When there are conflicts, these things happen:
 3. For conflicting paths, the index file records up to three
    versions; stage1 stores the version from the common ancestor,
    stage2 from `HEAD`, and stage3 from the remote branch (you
-   can inspect the stages with `git-ls-files -u`).  The working
+   can inspect the stages with `git ls-files -u`).  The working
    tree files have the result of "merge" program; i.e. 3-way
    merge result with familiar conflict markers `<<< === >>>`.
 
@@ -144,8 +143,8 @@ After seeing a conflict, you can do two things:
    up working tree changes made by 2. and 3.; `git-reset` can
    be used for this.
 
- * Resolve the conflicts.  `git-diff` would report only the
-   conflicting paths because of the above 2. and 3..  Edit the
+ * Resolve the conflicts.  `git diff` would report only the
+   conflicting paths because of the above 2. and 3.  Edit the
    working tree files into a desirable shape, `git-add` or `git-rm`
    them, to make the index file contain what the merge result
    should be, and run `git-commit` to commit the result.
@@ -154,8 +153,11 @@ After seeing a conflict, you can do two things:
 SEE ALSO
 --------
 linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
-linkgit:gitattributes[5]
-
+linkgit:gitattributes[5],
+linkgit:git-reset[1],
+linkgit:git-diff[1], linkgit:git-ls-files[1],
+linkgit:git-add[1], linkgit:git-rm[1],
+linkgit:git-mergetool[1]
 
 Author
 ------
diff --git a/git-mergetool.html b/git-mergetool.html
index 821d1ffac..fa1727feb 100644
--- a/git-mergetool.html
+++ b/git-mergetool.html
@@ -272,15 +272,15 @@ git-mergetool(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mergetool</em> [--tool=&lt;tool&gt;] [&lt;file&gt;]&#8230;</p>
+<p><em>git mergetool</em> [--tool=&lt;tool&gt;] [&lt;file&gt;]&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Use <tt>git mergetool</tt> to run one of several merge utilities to resolve
-merge conflicts.  It is typically run after <a href="git-merge.html">git-merge(1)</a>.</p>
+merge conflicts.  It is typically run after <tt>git-merge</tt>.</p>
 <p>If one or more &lt;file&gt; parameters are given, the merge tool program will
 be run to resolve differences on each file.  If no &lt;file&gt; names are
-specified, <tt>git mergetool</tt> will run the merge tool program on every file
+specified, <tt>git-mergetool</tt> will run the merge tool program on every file
 with merge conflicts.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -295,20 +295,20 @@ with merge conflicts.</p>
         Valid merge tools are:
         kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
 </p>
-<p>If a merge resolution program is not specified, <tt>git mergetool</tt>
+<p>If a merge resolution program is not specified, <tt>git-mergetool</tt>
 will use the configuration variable <tt>merge.tool</tt>.  If the
-configuration variable <tt>merge.tool</tt> is not set, <tt>git mergetool</tt>
+configuration variable <tt>merge.tool</tt> is not set, <tt>git-mergetool</tt>
 will pick a suitable default.</p>
 <p>You can explicitly provide a full path to the tool by setting the
 configuration variable <tt>mergetool.&lt;tool&gt;.path</tt>. For example, you
 can configure the absolute path to kdiff3 by setting
-<tt>mergetool.kdiff3.path</tt>. Otherwise, <tt>git mergetool</tt> assumes the
+<tt>mergetool.kdiff3.path</tt>. Otherwise, <tt>git-mergetool</tt> assumes the
 tool is available in PATH.</p>
 <p>Instead of running one of the known merge tool programs
-<tt>git mergetool</tt> can be customized to run an alternative program
+<tt>git-mergetool</tt> can be customized to run an alternative program
 by specifying the command line to invoke in a configration
 variable <tt>mergetool.&lt;tool&gt;.cmd</tt>.</p>
-<p>When <tt>git mergetool</tt> is invoked with this tool (either through the
+<p>When <tt>git-mergetool</tt> is invoked with this tool (either through the
 <tt>-t</tt> or <tt>--tool</tt> option or the <tt>merge.tool</tt> configuration
 variable) the configured command line will be invoked with <tt>$BASE</tt>
 set to the name of a temporary file containing the common base for
@@ -321,7 +321,7 @@ merge resolution.</p>
 <p>If the custom merge tool correctly indicates the success of a
 merge resolution with its exit code then the configuration
 variable <tt>mergetool.&lt;tool&gt;.trustExitCode</tt> can be set to <tt>true</tt>.
-Otherwise, <tt>git mergetool</tt> will prompt the user to indicate the
+Otherwise, <tt>git-mergetool</tt> will prompt the user to indicate the
 success of the resolution after the custom tool has exited.</p>
 </dd>
 </dl>
@@ -340,7 +340,7 @@ success of the resolution after the custom tool has exited.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:54 UTC
+Last updated 02-Jul-2008 03:01:53 UTC
 </div>
 </div>
 </body>
diff --git a/git-mergetool.txt b/git-mergetool.txt
index 83525609c..fedcfa054 100644
--- a/git-mergetool.txt
+++ b/git-mergetool.txt
@@ -7,17 +7,17 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
 
 SYNOPSIS
 --------
-'git-mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [<file>]...
 
 DESCRIPTION
 -----------
 
 Use `git mergetool` to run one of several merge utilities to resolve
-merge conflicts.  It is typically run after linkgit:git-merge[1].
+merge conflicts.  It is typically run after `git-merge`.
 
 If one or more <file> parameters are given, the merge tool program will
 be run to resolve differences on each file.  If no <file> names are
-specified, `git mergetool` will run the merge tool program on every file
+specified, `git-mergetool` will run the merge tool program on every file
 with merge conflicts.
 
 OPTIONS
@@ -27,23 +27,23 @@ OPTIONS
 	Valid merge tools are:
 	kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
 +
-If a merge resolution program is not specified, `git mergetool`
+If a merge resolution program is not specified, `git-mergetool`
 will use the configuration variable `merge.tool`.  If the
-configuration variable `merge.tool` is not set, `git mergetool`
+configuration variable `merge.tool` is not set, `git-mergetool`
 will pick a suitable default.
 +
 You can explicitly provide a full path to the tool by setting the
 configuration variable `mergetool.<tool>.path`. For example, you
 can configure the absolute path to kdiff3 by setting
-`mergetool.kdiff3.path`. Otherwise, `git mergetool` assumes the
+`mergetool.kdiff3.path`. Otherwise, `git-mergetool` assumes the
 tool is available in PATH.
 +
 Instead of running one of the known merge tool programs
-`git mergetool` can be customized to run an alternative program
+`git-mergetool` can be customized to run an alternative program
 by specifying the command line to invoke in a configration
 variable `mergetool.<tool>.cmd`.
 +
-When `git mergetool` is invoked with this tool (either through the
+When `git-mergetool` is invoked with this tool (either through the
 `-t` or `--tool` option or the `merge.tool` configuration
 variable) the configured command line will be invoked with `$BASE`
 set to the name of a temporary file containing the common base for
@@ -57,7 +57,7 @@ merge resolution.
 If the custom merge tool correctly indicates the success of a
 merge resolution with its exit code then the configuration
 variable `mergetool.<tool>.trustExitCode` can be set to `true`.
-Otherwise, `git mergetool` will prompt the user to indicate the
+Otherwise, `git-mergetool` will prompt the user to indicate the
 success of the resolution after the custom tool has exited.
 
 Author
diff --git a/git-mktag.html b/git-mktag.html
index 3e99ae4f6..27a03e600 100644
--- a/git-mktag.html
+++ b/git-mktag.html
@@ -272,7 +272,7 @@ git-mktag(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mktag</em> &lt; signature_file</p>
+<p><em>git mktag</em> &lt; signature_file</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -310,7 +310,7 @@ care about, but that can be verified with gpg.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:55 UTC
+Last updated 02-Jul-2008 03:01:54 UTC
 </div>
 </div>
 </body>
diff --git a/git-mktag.txt b/git-mktag.txt
index 232bc1a33..8bcc11443 100644
--- a/git-mktag.txt
+++ b/git-mktag.txt
@@ -8,7 +8,7 @@ git-mktag - Creates a tag object
 
 SYNOPSIS
 --------
-'git-mktag' < signature_file
+'git mktag' < signature_file
 
 DESCRIPTION
 -----------
diff --git a/git-mktree.html b/git-mktree.html
index 5c70a52bb..c11fdc780 100644
--- a/git-mktree.html
+++ b/git-mktree.html
@@ -272,7 +272,7 @@ git-mktree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mktree</em> [-z]</p>
+<p><em>git mktree</em> [-z]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -307,7 +307,7 @@ built is written to the standard output.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:56 UTC
+Last updated 02-Jul-2008 03:01:54 UTC
 </div>
 </div>
 </body>
diff --git a/git-mktree.txt b/git-mktree.txt
index 1ddbf00af..0be32e261 100644
--- a/git-mktree.txt
+++ b/git-mktree.txt
@@ -8,7 +8,7 @@ git-mktree - Build a tree-object from ls-tree formatted text
 
 SYNOPSIS
 --------
-'git-mktree' [-z]
+'git mktree' [-z]
 
 DESCRIPTION
 -----------
diff --git a/git-mv.html b/git-mv.html
index 7b9b61632..a264d9487 100644
--- a/git-mv.html
+++ b/git-mv.html
@@ -272,15 +272,15 @@ git-mv(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-mv</em> &lt;options&gt;&#8230; &lt;args&gt;&#8230;</p>
+<p><em>git mv</em> &lt;options&gt;&#8230; &lt;args&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>This script is used to move or rename a file, directory or symlink.</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-mv [-f] [-n] &lt;source&gt; &lt;destination&gt;
-git-mv [-f] [-n] [-k] &lt;source&gt; ... &lt;destination directory&gt;</tt></pre>
+<pre><tt>git mv [-f] [-n] &lt;source&gt; &lt;destination&gt;
+git mv [-f] [-n] [-k] &lt;source&gt; ... &lt;destination directory&gt;</tt></pre>
 </div></div>
 <p>In the first form, it renames &lt;source&gt;, which must exist and be either
 a file, symlink or directory, to &lt;destination&gt;.
@@ -340,7 +340,7 @@ Move functionality added by Josef Weidendorfer &lt;Josef.Weidendorfer@gmx.de&gt;
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:50 UTC
+Last updated 02-Jul-2008 03:01:54 UTC
 </div>
 </div>
 </body>
diff --git a/git-mv.txt b/git-mv.txt
index 339190600..9c5660275 100644
--- a/git-mv.txt
+++ b/git-mv.txt
@@ -8,14 +8,14 @@ git-mv - Move or rename a file, a directory, or a symlink
 
 SYNOPSIS
 --------
-'git-mv' <options>... <args>...
+'git mv' <options>... <args>...
 
 DESCRIPTION
 -----------
 This script is used to move or rename a file, directory or symlink.
 
- git-mv [-f] [-n] <source> <destination>
- git-mv [-f] [-n] [-k] <source> ... <destination directory>
+ git mv [-f] [-n] <source> <destination>
+ git mv [-f] [-n] [-k] <source> ... <destination directory>
 
 In the first form, it renames <source>, which must exist and be either
 a file, symlink or directory, to <destination>.
diff --git a/git-name-rev.html b/git-name-rev.html
index e85db1b82..b7ea7adb3 100644
--- a/git-name-rev.html
+++ b/git-name-rev.html
@@ -273,13 +273,13 @@ git-name-rev(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-name-rev</em> [--tags] [--refs=&lt;pattern&gt;]
+<div class="content"><em>git name-rev</em> [--tags] [--refs=&lt;pattern&gt;]
                ( --all | --stdin | &lt;committish&gt;&#8230; )</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Finds symbolic names suitable for human digestion for revisions given in any
-format parsable by git-rev-parse.</p>
+format parsable by <tt>git-rev-parse</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -325,7 +325,7 @@ format parsable by git-rev-parse.</p>
         Instead of printing both the SHA-1 and the name, print only
         the name.  If given with --tags the usual tag prefix of
         "tags/" is also omitted from the name, matching the output
-        of <a href="git-describe.html">git-describe(1)</a> more closely.  This option
+        of <tt>git-describe</tt> more closely.  This option
         cannot be combined with --stdin.
 </p>
 </dd>
@@ -354,7 +354,7 @@ format parsable by git-rev-parse.</p>
 wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
 Of course, you look into the commit, but that only tells you what happened, but
 not the context.</p>
-<p>Enter git-name-rev:</p>
+<p>Enter <tt>git-name-rev</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
@@ -381,7 +381,7 @@ not the context.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:50 UTC
+Last updated 02-Jul-2008 03:01:54 UTC
 </div>
 </div>
 </body>
diff --git a/git-name-rev.txt b/git-name-rev.txt
index ffac3f8f5..00b1fa4dc 100644
--- a/git-name-rev.txt
+++ b/git-name-rev.txt
@@ -9,13 +9,13 @@ git-name-rev - Find symbolic names for given revs
 SYNOPSIS
 --------
 [verse]
-'git-name-rev' [--tags] [--refs=<pattern>]
+'git name-rev' [--tags] [--refs=<pattern>]
 	       ( --all | --stdin | <committish>... )
 
 DESCRIPTION
 -----------
 Finds symbolic names suitable for human digestion for revisions given in any
-format parsable by git-rev-parse.
+format parsable by `git-rev-parse`.
 
 
 OPTIONS
@@ -38,7 +38,7 @@ OPTIONS
 	Instead of printing both the SHA-1 and the name, print only
 	the name.  If given with --tags the usual tag prefix of
 	"tags/" is also omitted from the name, matching the output
-	of linkgit:git-describe[1] more closely.  This option
+	of `git-describe` more closely.  This option
 	cannot be combined with --stdin.
 
 --no-undefined::
@@ -56,7 +56,7 @@ wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
 Of course, you look into the commit, but that only tells you what happened, but
 not the context.
 
-Enter git-name-rev:
+Enter `git-name-rev`:
 
 ------------
 % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
diff --git a/git-pack-objects.html b/git-pack-objects.html
index 12673e8ff..b90d2766f 100644
--- a/git-pack-objects.html
+++ b/git-pack-objects.html
@@ -273,7 +273,7 @@ git-pack-objects(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-pack-objects</em> [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
+<div class="content"><em>git pack-objects</em> [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
         [--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
         [--revs [--unpacked | --all]*] [--stdout | base-name] &lt; object-list</div></div>
 </div>
@@ -290,7 +290,7 @@ in the pack, a pack index file (.idx) will be generated.</p>
 <p>Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
 enables git to read from such an archive.</p>
-<p><em>git-unpack-objects</em> command can read the packed archive and
+<p>The <tt>git-unpack-objects</tt> command can read the packed archive and
 expand the objects contained in the pack into "one-file
 one-object" format; this is typically done by the smart-pull
 commands when a pack is created on-the-fly for efficient network
@@ -332,7 +332,7 @@ base-name
 <p>
         Read the revision arguments from the standard input, instead of
         individual object names.  The revision arguments are processed
-        the same way as <a href="git-rev-list.html">git-rev-list(1)</a> with <tt>--objects</tt> flag
+        the same way as <tt>git-rev-list</tt> with the <tt>--objects</tt> flag
         uses its <tt>commit</tt> arguments to build the list of objects it
         outputs.  The objects on the resulting list are packed.
 </p>
@@ -525,7 +525,7 @@ base-name
         A packed archive can express base object of a delta as
         either 20-byte object name or as an offset in the
         stream, but older version of git does not understand the
-        latter.  By default, git-pack-objects only uses the
+        latter.  By default, <tt>git-pack-objects</tt> only uses the
         former format for better compatibility.  This option
         allows the command to use the latter format for
         compactness.  Depending on the average delta chain
@@ -580,7 +580,7 @@ base-name
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:51 UTC
+Last updated 02-Jul-2008 03:01:54 UTC
 </div>
 </div>
 </body>
diff --git a/git-pack-objects.txt b/git-pack-objects.txt
index f4d8d68e3..d9cd16ae1 100644
--- a/git-pack-objects.txt
+++ b/git-pack-objects.txt
@@ -9,7 +9,7 @@ git-pack-objects - Create a packed archive of objects
 SYNOPSIS
 --------
 [verse]
-'git-pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
+'git pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
 	[--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
 	[--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
 
@@ -30,7 +30,7 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
 enables git to read from such an archive.
 
-'git-unpack-objects' command can read the packed archive and
+The `git-unpack-objects` command can read the packed archive and
 expand the objects contained in the pack into "one-file
 one-object" format; this is typically done by the smart-pull
 commands when a pack is created on-the-fly for efficient network
@@ -59,7 +59,7 @@ base-name::
 --revs::
 	Read the revision arguments from the standard input, instead of
 	individual object names.  The revision arguments are processed
-	the same way as linkgit:git-rev-list[1] with `--objects` flag
+	the same way as `git-rev-list` with the `--objects` flag
 	uses its `commit` arguments to build the list of objects it
 	outputs.  The objects on the resulting list are packed.
 
@@ -163,14 +163,14 @@ base-name::
 	generated pack.  If not specified,  pack compression level is
 	determined first by pack.compression,  then by core.compression,
 	and defaults to -1,  the zlib default,  if neither is set.
-	Add \--no-reuse-object if you want to force a uniform compression
+	Add --no-reuse-object if you want to force a uniform compression
 	level on all data no matter the source.
 
 --delta-base-offset::
 	A packed archive can express base object of a delta as
 	either 20-byte object name or as an offset in the
 	stream, but older version of git does not understand the
-	latter.  By default, git-pack-objects only uses the
+	latter.  By default, `git-pack-objects` only uses the
 	former format for better compatibility.  This option
 	allows the command to use the latter format for
 	compactness.  Depending on the average delta chain
diff --git a/git-pack-redundant.html b/git-pack-redundant.html
index 0271e1db7..da6507b05 100644
--- a/git-pack-redundant.html
+++ b/git-pack-redundant.html
@@ -272,18 +272,18 @@ git-pack-redundant(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-pack-redundant</em> [ --verbose ] [ --alt-odb ] &lt; --all | .pack filename &#8230; &gt;</p>
+<p><em>git pack-redundant</em> [ --verbose ] [ --alt-odb ] &lt; --all | .pack filename &#8230; &gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>This program computes which packs in your repository
 are redundant. The output is suitable for piping to
-<em>xargs rm</em> if you are in the root of the repository.</p>
-<p>git-pack-redundant accepts a list of objects on standard input. Any objects
+<tt>xargs rm</tt> if you are in the root of the repository.</p>
+<p><tt>git-pack-redundant</tt> accepts a list of objects on standard input. Any objects
 given will be ignored when checking which packs are required. This makes the
 following command useful when wanting to remove packs which contain unreachable
 objects.</p>
-<p>git-fsck --full --unreachable | cut -d <em> </em> -f3 | git-pack-redundant --all | xargs rm</p>
+<p>git fsck --full --unreachable | cut -d <em> </em> -f3 | git pack-redundant --all | xargs rm</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -335,7 +335,7 @@ objects.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:57 UTC
+Last updated 02-Jul-2008 03:01:55 UTC
 </div>
 </div>
 </body>
diff --git a/git-pack-redundant.txt b/git-pack-redundant.txt
index 6737326f0..80fc1bae3 100644
--- a/git-pack-redundant.txt
+++ b/git-pack-redundant.txt
@@ -8,21 +8,21 @@ git-pack-redundant - Find redundant pack files
 
 SYNOPSIS
 --------
-'git-pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
+'git pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
 
 DESCRIPTION
 -----------
 This program computes which packs in your repository
 are redundant. The output is suitable for piping to
-'xargs rm' if you are in the root of the repository.
+`xargs rm` if you are in the root of the repository.
 
-git-pack-redundant accepts a list of objects on standard input. Any objects
+`git-pack-redundant` accepts a list of objects on standard input. Any objects
 given will be ignored when checking which packs are required. This makes the
 following command useful when wanting to remove packs which contain unreachable
 objects.
 
-git-fsck --full --unreachable | cut -d ' ' -f3 | \
-git-pack-redundant --all | xargs rm
+git fsck --full --unreachable | cut -d ' ' -f3 | \
+git pack-redundant --all | xargs rm
 
 OPTIONS
 -------
diff --git a/git-pack-refs.html b/git-pack-refs.html
index 007dc0763..11a8c42e5 100644
--- a/git-pack-refs.html
+++ b/git-pack-refs.html
@@ -272,7 +272,7 @@ git-pack-refs(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-pack-refs</em> [--all] [--no-prune]</p>
+<p><em>git pack-refs</em> [--all] [--no-prune]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -292,7 +292,7 @@ file and used if found.</p>
 <tt>$GIT_DIR/refs</tt> hierarchy.</p>
 <p>A recommended practice to deal with a repository with too many
 refs is to pack its refs with <tt>--all --prune</tt> once, and
-occasionally run <tt>git-pack-refs --prune</tt>.  Tags are by
+occasionally run <tt>git pack-refs --prune</tt>.  Tags are by
 definition stationary and are not expected to change.  Branch
 heads will be packed with the initial <tt>pack-refs --all</tt>, but
 only the currently active branch heads will become unpacked,
@@ -336,7 +336,7 @@ hierarchy after packing them.  This option tells it not to.
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:52 UTC
+Last updated 02-Jul-2008 03:01:55 UTC
 </div>
 </div>
 </body>
diff --git a/git-pack-refs.txt b/git-pack-refs.txt
index c0718468d..a5244d35f 100644
--- a/git-pack-refs.txt
+++ b/git-pack-refs.txt
@@ -7,7 +7,7 @@ git-pack-refs - Pack heads and tags for efficient repository access
 
 SYNOPSIS
 --------
-'git-pack-refs' [--all] [--no-prune]
+'git pack-refs' [--all] [--no-prune]
 
 DESCRIPTION
 -----------
@@ -31,7 +31,7 @@ Subsequent updates to branches always creates new file under
 
 A recommended practice to deal with a repository with too many
 refs is to pack its refs with `--all --prune` once, and
-occasionally run `git-pack-refs \--prune`.  Tags are by
+occasionally run `git pack-refs \--prune`.  Tags are by
 definition stationary and are not expected to change.  Branch
 heads will be packed with the initial `pack-refs --all`, but
 only the currently active branch heads will become unpacked,
diff --git a/git-parse-remote.html b/git-parse-remote.html
index a64800b4e..eed90d69b 100644
--- a/git-parse-remote.html
+++ b/git-parse-remote.html
@@ -326,7 +326,7 @@ get_remote_refs_for_push
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 30-Jun-2008 09:04:38 UTC
+Last updated 02-Jul-2008 03:01:55 UTC
 </div>
 </div>
 </body>
diff --git a/git-patch-id.html b/git-patch-id.html
index e5a8f869b..0e4645c81 100644
--- a/git-patch-id.html
+++ b/git-patch-id.html
@@ -272,7 +272,7 @@ git-patch-id(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-patch-id</em> &lt; &lt;patch&gt;</p>
+<p><em>git patch-id</em> &lt; &lt;patch&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,7 +281,7 @@ whitespace and line numbers ignored.  As such, it's "reasonably stable", but at
 the same time also reasonably unique, i.e., two patches that have the same "patch
 ID" are almost guaranteed to be the same thing.</p>
 <p>IOW, you can use this thing to look for likely duplicate commits.</p>
-<p>When dealing with git-diff-tree output, it takes advantage of
+<p>When dealing with <tt>git-diff-tree</tt> output, it takes advantage of
 the fact that the patch is prefixed with the object name of the
 commit, and outputs two 40-byte hexadecimal string.  The first
 string is the patch ID, and the second string is the commit ID.
@@ -314,7 +314,7 @@ This can be used to make a mapping from patch ID to commit ID.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:59 UTC
+Last updated 02-Jul-2008 03:01:55 UTC
 </div>
 </div>
 </body>
diff --git a/git-patch-id.txt b/git-patch-id.txt
index bb8a07925..17c178f86 100644
--- a/git-patch-id.txt
+++ b/git-patch-id.txt
@@ -7,7 +7,7 @@ git-patch-id - Compute unique ID for a patch
 
 SYNOPSIS
 --------
-'git-patch-id' < <patch>
+'git patch-id' < <patch>
 
 DESCRIPTION
 -----------
@@ -18,7 +18,7 @@ ID" are almost guaranteed to be the same thing.
 
 IOW, you can use this thing to look for likely duplicate commits.
 
-When dealing with git-diff-tree output, it takes advantage of
+When dealing with `git-diff-tree` output, it takes advantage of
 the fact that the patch is prefixed with the object name of the
 commit, and outputs two 40-byte hexadecimal string.  The first
 string is the patch ID, and the second string is the commit ID.
diff --git a/git-peek-remote.html b/git-peek-remote.html
index f2c5f24be..06d601607 100644
--- a/git-peek-remote.html
+++ b/git-peek-remote.html
@@ -272,7 +272,7 @@ git-peek-remote(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-peek-remote</em> [--upload-pack=&lt;git-upload-pack&gt;] [&lt;host&gt;:]&lt;directory&gt;</p>
+<p><em>git peek-remote</em> [--upload-pack=&lt;git-upload-pack&gt;] [&lt;host&gt;:]&lt;directory&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -286,7 +286,7 @@ git-peek-remote(1) Manual Page
 </dt>
 <dd>
 <p>
-        Use this to specify the path to <em>git-upload-pack</em> on the
+        Use this to specify the path to <tt>git-upload-pack</tt> on the
         remote side, if it is not found on your $PATH. Some
         installations of sshd ignores the user's environment
         setup scripts for login shells (e.g. .bash_profile) and
@@ -304,7 +304,7 @@ git-peek-remote(1) Manual Page
 <dd>
 <p>
         A remote host that houses the repository.  When this
-        part is specified, <em>git-upload-pack</em> is invoked via
+        part is specified, <tt>git-upload-pack</tt> is invoked via
         ssh.
 </p>
 </dd>
@@ -332,7 +332,7 @@ git-peek-remote(1) Manual Page
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:53 UTC
+Last updated 02-Jul-2008 03:01:55 UTC
 </div>
 </div>
 </body>
diff --git a/git-peek-remote.txt b/git-peek-remote.txt
index ffbf93a79..c3ed4a10f 100644
--- a/git-peek-remote.txt
+++ b/git-peek-remote.txt
@@ -8,7 +8,7 @@ git-peek-remote - List the references in a remote repository
 
 SYNOPSIS
 --------
-'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
+'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
 
 DESCRIPTION
 -----------
@@ -17,7 +17,7 @@ This command is deprecated; use `git-ls-remote` instead.
 OPTIONS
 -------
 --upload-pack=<git-upload-pack>::
-	Use this to specify the path to 'git-upload-pack' on the
+	Use this to specify the path to `git-upload-pack` on the
 	remote side, if it is not found on your $PATH. Some
 	installations of sshd ignores the user's environment
 	setup scripts for login shells (e.g. .bash_profile) and
@@ -30,7 +30,7 @@ OPTIONS
 
 <host>::
 	A remote host that houses the repository.  When this
-	part is specified, 'git-upload-pack' is invoked via
+	part is specified, `git-upload-pack` is invoked via
 	ssh.
 
 <directory>::
diff --git a/git-prune-packed.html b/git-prune-packed.html
index fdab7ef8a..e91c661c7 100644
--- a/git-prune-packed.html
+++ b/git-prune-packed.html
@@ -272,7 +272,7 @@ git-prune-packed(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-prune-packed</em> [-n] [-q]</p>
+<p><em>git prune-packed</em> [-n] [-q]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -325,7 +325,7 @@ disk storage, etc.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:33:59 UTC
+Last updated 02-Jul-2008 03:01:56 UTC
 </div>
 </div>
 </body>
diff --git a/git-prune-packed.txt b/git-prune-packed.txt
index f330b8a5b..b5f26cee1 100644
--- a/git-prune-packed.txt
+++ b/git-prune-packed.txt
@@ -8,7 +8,7 @@ git-prune-packed - Remove extra objects that are already in pack files
 
 SYNOPSIS
 --------
-'git-prune-packed' [-n] [-q]
+'git prune-packed' [-n] [-q]
 
 
 DESCRIPTION
diff --git a/git-prune.html b/git-prune.html
index 41b269304..e6bc772c3 100644
--- a/git-prune.html
+++ b/git-prune.html
@@ -281,8 +281,8 @@ git-prune(1) Manual Page
 <td class="icon">
 <div class="title">Note</div>
 </td>
-<td class="content">In most cases, users should run <a href="git-gc.html">git-gc(1)</a>, which calls
-git-prune. See the section "NOTES", below.</td>
+<td class="content">In most cases, users should run <tt>git-gc</tt>, which calls
+<tt>git-prune</tt>. See the section "NOTES", below.</td>
 </tr></table>
 </div>
 <p>This runs <tt>git-fsck --unreachable</tt> using all the refs
@@ -291,7 +291,7 @@ objects specified on the command line, and prunes all unpacked
 objects unreachable from any of these head objects from the object database.
 In addition, it
 prunes the unpacked objects that are also found in packs by
-running <tt>git prune-packed</tt>.</p>
+running <tt>git-prune-packed</tt>.</p>
 <p>Note that unreachable, packed objects will remain.  If this is
 not desired, see <a href="git-repack.html">git-repack(1)</a>.</p>
 </div>
@@ -342,16 +342,16 @@ borrows from your repository via its
 <tt>.git/objects/info/alternates</tt>:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git prune $(cd ../another &amp;&amp; $(git-rev-parse --all))</tt></pre>
+<pre><tt>$ git prune $(cd ../another &amp;&amp; $(git rev-parse --all))</tt></pre>
 </div></div>
 </div>
 <h2>Notes</h2>
 <div class="sectionbody">
-<p>In most cases, users will not need to call git-prune directly, but
-should instead call <a href="git-gc.html">git-gc(1)</a>, which handles pruning along with
+<p>In most cases, users will not need to call <tt>git-prune</tt> directly, but
+should instead call <tt>git-gc</tt>, which handles pruning along with
 many other housekeeping tasks.</p>
 <p>For a description of which objects are considered for pruning, see
-git-fsck's --unreachable option.</p>
+<tt>git-fsck</tt>'s --unreachable option.</p>
 </div>
 <h2>SEE ALSO</h2>
 <div class="sectionbody">
@@ -373,7 +373,7 @@ git-fsck's --unreachable option.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:53 UTC
+Last updated 02-Jul-2008 03:01:56 UTC
 </div>
 </div>
 </body>
diff --git a/git-prune.txt b/git-prune.txt
index ec335d6fa..a4a0d56ca 100644
--- a/git-prune.txt
+++ b/git-prune.txt
@@ -13,8 +13,8 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-NOTE: In most cases, users should run linkgit:git-gc[1], which calls
-git-prune. See the section "NOTES", below.
+NOTE: In most cases, users should run `git-gc`, which calls
+`git-prune`. See the section "NOTES", below.
 
 This runs `git-fsck --unreachable` using all the refs
 available in `$GIT_DIR/refs`, optionally with additional set of
@@ -22,7 +22,7 @@ objects specified on the command line, and prunes all unpacked
 objects unreachable from any of these head objects from the object database.
 In addition, it
 prunes the unpacked objects that are also found in packs by
-running `git prune-packed`.
+running `git-prune-packed`.
 
 Note that unreachable, packed objects will remain.  If this is
 not desired, see linkgit:git-repack[1].
@@ -53,18 +53,18 @@ borrows from your repository via its
 `.git/objects/info/alternates`:
 
 ------------
-$ git prune $(cd ../another && $(git-rev-parse --all))
+$ git prune $(cd ../another && $(git rev-parse --all))
 ------------
 
 Notes
 -----
 
-In most cases, users will not need to call git-prune directly, but
-should instead call linkgit:git-gc[1], which handles pruning along with
+In most cases, users will not need to call `git-prune` directly, but
+should instead call `git-gc`, which handles pruning along with
 many other housekeeping tasks.
 
 For a description of which objects are considered for pruning, see
-git-fsck's --unreachable option.
+`git-fsck`'s --unreachable option.
 
 SEE ALSO
 --------
diff --git a/git-pull.html b/git-pull.html
index 8b9e1ec17..61be7a31e 100644
--- a/git-pull.html
+++ b/git-pull.html
@@ -272,7 +272,7 @@ git-pull(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-pull</em> &lt;options&gt; &lt;repository&gt; &lt;refspec&gt;&#8230;</p>
+<p><em>git pull</em> &lt;options&gt; &lt;repository&gt; &lt;refspec&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -1078,8 +1078,7 @@ the others will not be.</p>
 </li>
 </ul>
 <p>If you tried a pull which resulted in a complex conflicts and
-would want to start over, you can recover with
-<a href="git-reset.html">git-reset(1)</a>.</p>
+would want to start over, you can recover with <tt>git-reset</tt>.</p>
 </div>
 <h2>SEE ALSO</h2>
 <div class="sectionbody">
@@ -1102,7 +1101,7 @@ Junio C Hamano and the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:42 UTC
+Last updated 02-Jul-2008 03:01:56 UTC
 </div>
 </div>
 </body>
diff --git a/git-pull.txt b/git-pull.txt
index d0f1595f7..d9537ebc6 100644
--- a/git-pull.txt
+++ b/git-pull.txt
@@ -8,7 +8,7 @@ git-pull - Fetch from and merge with another repository or a local branch
 
 SYNOPSIS
 --------
-'git-pull' <options> <repository> <refspec>...
+'git pull' <options> <repository> <refspec>...
 
 
 DESCRIPTION
@@ -182,8 +182,7 @@ The final command then merges the newly fetched `tmp` into master.
 
 
 If you tried a pull which resulted in a complex conflicts and
-would want to start over, you can recover with
-linkgit:git-reset[1].
+would want to start over, you can recover with `git-reset`.
 
 
 SEE ALSO
diff --git a/git-push.html b/git-push.html
index 16cd74585..4697ad8f5 100644
--- a/git-push.html
+++ b/git-push.html
@@ -273,7 +273,7 @@ git-push(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-push</em> [--all] [--dry-run] [--tags] [--receive-pack=&lt;git-receive-pack&gt;]
+<div class="content"><em>git push</em> [--all] [--dry-run] [--tags] [--receive-pack=&lt;git-receive-pack&gt;]
            [--repo=all] [-f | --force] [-v | --verbose] [&lt;repository&gt; &lt;refspec&gt;&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
@@ -375,7 +375,7 @@ nor in any Push line of the corresponding remotes file---see below).</p>
 </dt>
 <dd>
 <p>
-        Path to the <em>git-receive-pack</em> program on the remote
+        Path to the <tt>git-receive-pack</tt> program on the remote
         end.  Sometimes useful when pushing to a remote
         repository over ssh, and you do not have the program in
         a directory on the default $PATH.
@@ -769,7 +769,7 @@ by Linus Torvalds &lt;torvalds@osdl.org&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 21-Jun-2008 09:40:20 UTC
+Last updated 02-Jul-2008 03:01:56 UTC
 </div>
 </div>
 </body>
diff --git a/git-push.txt b/git-push.txt
index f3d5d883a..1f70e7275 100644
--- a/git-push.txt
+++ b/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 SYNOPSIS
 --------
 [verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
            [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
 
 DESCRIPTION
@@ -85,7 +85,7 @@ nor in any Push line of the corresponding remotes file---see below).
 	line.
 
 --receive-pack=<git-receive-pack>::
-	Path to the 'git-receive-pack' program on the remote
+	Path to the `git-receive-pack` program on the remote
 	end.  Sometimes useful when pushing to a remote
 	repository over ssh, and you do not have the program in
 	a directory on the default $PATH.
diff --git a/git-quiltimport.html b/git-quiltimport.html
index 719f1e376..3b1ff543a 100644
--- a/git-quiltimport.html
+++ b/git-quiltimport.html
@@ -273,7 +273,7 @@ git-quiltimport(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-quiltimport</em> [--dry-run] [--author &lt;author&gt;] [--patches &lt;dir&gt;]</div></div>
+<div class="content"><em>git quiltimport</em> [--dry-run] [--author &lt;author&gt;] [--patches &lt;dir&gt;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -342,7 +342,7 @@ variable.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:56 UTC
+Last updated 02-Jul-2008 03:01:57 UTC
 </div>
 </div>
 </body>
diff --git a/git-quiltimport.txt b/git-quiltimport.txt
index 060037939..d4037de51 100644
--- a/git-quiltimport.txt
+++ b/git-quiltimport.txt
@@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchset onto the current branch
 SYNOPSIS
 --------
 [verse]
-'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
+'git quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
 
 
 DESCRIPTION
diff --git a/git-read-tree.html b/git-read-tree.html
index 1f405709e..f11717ecc 100644
--- a/git-read-tree.html
+++ b/git-read-tree.html
@@ -272,7 +272,7 @@ git-read-tree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-read-tree</em> (&lt;tree-ish&gt; | [[-m [--trivial] [--aggressive] | --reset | --prefix=&lt;prefix&gt;] [-u | -i]] [--exclude-per-directory=&lt;gitignore&gt;] [--index-output=&lt;file&gt;] &lt;tree-ish1&gt; [&lt;tree-ish2&gt; [&lt;tree-ish3&gt;]])</p>
+<p><em>git read-tree</em> (&lt;tree-ish&gt; | [[-m [--trivial] [--aggressive] | --reset | --prefix=&lt;prefix&gt;] [-u | -i]] [--exclude-per-directory=&lt;gitignore&gt;] [--index-output=&lt;file&gt;] &lt;tree-ish1&gt; [&lt;tree-ish2&gt; [&lt;tree-ish3&gt;]])</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -449,22 +449,22 @@ merge, a single tree merge if only 1 tree is given, a
 fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
 provided.</p>
 <h3>Single Tree Merge</h3>
-<p>If only 1 tree is specified, git-read-tree operates as if the user did not
+<p>If only 1 tree is specified, <tt>git-read-tree</tt> operates as if the user did not
 specify <tt>-m</tt>, except that if the original index has an entry for a
 given pathname, and the contents of the path matches with the tree
 being read, the stat info from the index is used. (In other words, the
 index's stat()s take precedence over the merged tree's).</p>
-<p>That means that if you do a <tt>git-read-tree -m &lt;newtree&gt;</tt> followed by a
-<tt>git-checkout-index -f -u -a</tt>, the <tt>git-checkout-index</tt> only checks out
+<p>That means that if you do a <tt>git read-tree -m &lt;newtree&gt;</tt> followed by a
+<tt>git checkout-index -f -u -a</tt>, the <tt>git-checkout-index</tt> only checks out
 the stuff that really changed.</p>
 <p>This is used to avoid unnecessary false hits when <tt>git-diff-files</tt> is
 run after <tt>git-read-tree</tt>.</p>
 <h3>Two Tree Merge</h3>
-<p>Typically, this is invoked as <tt>git-read-tree -m $H $M</tt>, where $H
+<p>Typically, this is invoked as <tt>git read-tree -m $H $M</tt>, where $H
 is the head commit of the current repository, and $M is the head
 of a foreign tree, which is simply ahead of $H (i.e. we are in a
 fast forward situation).</p>
-<p>When two trees are specified, the user is telling git-read-tree
+<p>When two trees are specified, the user is telling <tt>git-read-tree</tt>
 the following:</p>
 <ol>
 <li>
@@ -479,7 +479,7 @@ The user wants to fast-forward to $M.
 </p>
 </li>
 </ol>
-<p>In this case, the <tt>git-read-tree -m $H $M</tt> command makes sure
+<p>In this case, the <tt>git read-tree -m $H $M</tt> command makes sure
 that no local change is lost as the result of this "merge".
 Here are the "carry forward" rules:</p>
 <div class="literalblock">
@@ -532,17 +532,17 @@ Here are the "carry forward" rules:</p>
 </div></div>
 <p>In all "keep index" cases, the index entry stays as in the
 original index file.  If the entry were not up to date,
-git-read-tree keeps the copy in the work tree intact when
+<tt>git-read-tree</tt> keeps the copy in the work tree intact when
 operating under the -u flag.</p>
-<p>When this form of git-read-tree returns successfully, you can
+<p>When this form of <tt>git-read-tree</tt> returns successfully, you can
 see what "local changes" you made are carried forward by running
-<tt>git-diff-index --cached $M</tt>.  Note that this does not
-necessarily match <tt>git-diff-index --cached $H</tt> would have
+<tt>git diff-index --cached $M</tt>.  Note that this does not
+necessarily match <tt>git diff-index --cached $H</tt> would have
 produced before such a two tree merge.  This is because of cases
 18 and 19 --- if you already had the changes in $M (e.g. maybe
-you picked it up via e-mail in a patch form), <tt>git-diff-index
+you picked it up via e-mail in a patch form), <tt>git diff-index
 --cached $H</tt> would have told you about the change before this
-merge, but it would not show in <tt>git-diff-index --cached $M</tt>
+merge, but it would not show in <tt>git diff-index --cached $M</tt>
 output after two-tree merge.</p>
 <h3>3-Way Merge</h3>
 <p>Each "index" entry has two bits worth of "stage" state. stage 0 is the
@@ -552,7 +552,7 @@ starts out at 1.</p>
 <p>This means that you can do</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-read-tree -m &lt;tree1&gt; &lt;tree2&gt; &lt;tree3&gt;</tt></pre>
+<pre><tt>$ git read-tree -m &lt;tree1&gt; &lt;tree2&gt; &lt;tree3&gt;</tt></pre>
 </div></div>
 <p>and you will end up with an index with all of the &lt;tree1&gt; entries in
 "stage1", all of the &lt;tree2&gt; entries in "stage2" and all of the
@@ -602,7 +602,7 @@ populated.  Here is an outline of how the algorithm works:</p>
 <li>
 <p>
 if a file exists in identical format in all three trees, it will
-  automatically collapse to "merged" state by git-read-tree.
+  automatically collapse to "merged" state by <tt>git-read-tree</tt>.
 </p>
 </li>
 <li>
@@ -662,15 +662,15 @@ commit.  To illustrate, suppose you start from what has been
 committed last to your repository:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ JC=`git-rev-parse --verify "HEAD^0"`
-$ git-checkout-index -f -u -a $JC</tt></pre>
+<pre><tt>$ JC=`git rev-parse --verify "HEAD^0"`
+$ git checkout-index -f -u -a $JC</tt></pre>
 </div></div>
-<p>You do random edits, without running git-update-index.  And then
+<p>You do random edits, without running <tt>git-update-index</tt>.  And then
 you notice that the tip of your "upstream" tree has advanced
 since you pulled from him:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-fetch git://.... linus
+<pre><tt>$ git fetch git://.... linus
 $ LT=`cat .git/FETCH_HEAD`</tt></pre>
 </div></div>
 <p>Your work tree is still based on your HEAD ($JC), but you have
@@ -679,16 +679,16 @@ added or modified index entries since $JC, and if you haven't,
 then does the right thing.  So with the following sequence:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
-$ git-merge-index git-merge-one-file -a
+<pre><tt>$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
+$ git merge-index git-merge-one-file -a
 $ echo "Merge with Linus" | \
-  git-commit-tree `git-write-tree` -p $JC -p $LT</tt></pre>
+  git commit-tree `git write-tree` -p $JC -p $LT</tt></pre>
 </div></div>
 <p>what you would commit is a pure merge between $JC and $LT without
 your work-in-progress changes, and your work tree would be
 updated to the result of the merge.</p>
 <p>However, if you have local changes in the working tree that
-would be overwritten by this merge,<tt>git-read-tree</tt> will refuse
+would be overwritten by this merge, <tt>git-read-tree</tt> will refuse
 to run to prevent your changes from being lost.</p>
 <p>In other words, there is no need to worry about what exists only
 in the working tree.  When you have local changes in a part of
@@ -719,7 +719,7 @@ have finished your work-in-progress), attempt the merge again.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 10-Jun-2008 04:10:01 UTC
+Last updated 02-Jul-2008 03:01:57 UTC
 </div>
 </div>
 </body>
diff --git a/git-read-tree.txt b/git-read-tree.txt
index 58fb906ef..0c7cc6b94 100644
--- a/git-read-tree.txt
+++ b/git-read-tree.txt
@@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
 
 SYNOPSIS
 --------
-'git-read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+'git read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
 
 
 DESCRIPTION
@@ -121,14 +121,14 @@ provided.
 
 Single Tree Merge
 ~~~~~~~~~~~~~~~~~
-If only 1 tree is specified, git-read-tree operates as if the user did not
+If only 1 tree is specified, `git-read-tree` operates as if the user did not
 specify `-m`, except that if the original index has an entry for a
 given pathname, and the contents of the path matches with the tree
 being read, the stat info from the index is used. (In other words, the
 index's stat()s take precedence over the merged tree's).
 
-That means that if you do a `git-read-tree -m <newtree>` followed by a
-`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
+That means that if you do a `git read-tree -m <newtree>` followed by a
+`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
 the stuff that really changed.
 
 This is used to avoid unnecessary false hits when `git-diff-files` is
@@ -138,12 +138,12 @@ run after `git-read-tree`.
 Two Tree Merge
 ~~~~~~~~~~~~~~
 
-Typically, this is invoked as `git-read-tree -m $H $M`, where $H
+Typically, this is invoked as `git read-tree -m $H $M`, where $H
 is the head commit of the current repository, and $M is the head
 of a foreign tree, which is simply ahead of $H (i.e. we are in a
 fast forward situation).
 
-When two trees are specified, the user is telling git-read-tree
+When two trees are specified, the user is telling `git-read-tree`
 the following:
 
      1. The current index and work tree is derived from $H, but
@@ -151,7 +151,7 @@ the following:
 
      2. The user wants to fast-forward to $M.
 
-In this case, the `git-read-tree -m $H $M` command makes sure
+In this case, the `git read-tree -m $H $M` command makes sure
 that no local change is lost as the result of this "merge".
 Here are the "carry forward" rules:
 
@@ -193,18 +193,18 @@ Here are the "carry forward" rules:
 
 In all "keep index" cases, the index entry stays as in the
 original index file.  If the entry were not up to date,
-git-read-tree keeps the copy in the work tree intact when
+`git-read-tree` keeps the copy in the work tree intact when
 operating under the -u flag.
 
-When this form of git-read-tree returns successfully, you can
+When this form of `git-read-tree` returns successfully, you can
 see what "local changes" you made are carried forward by running
-`git-diff-index --cached $M`.  Note that this does not
-necessarily match `git-diff-index --cached $H` would have
+`git diff-index --cached $M`.  Note that this does not
+necessarily match `git diff-index --cached $H` would have
 produced before such a two tree merge.  This is because of cases
 18 and 19 --- if you already had the changes in $M (e.g. maybe
-you picked it up via e-mail in a patch form), `git-diff-index
+you picked it up via e-mail in a patch form), `git diff-index
 --cached $H` would have told you about the change before this
-merge, but it would not show in `git-diff-index --cached $M`
+merge, but it would not show in `git diff-index --cached $M`
 output after two-tree merge.
 
 
@@ -219,7 +219,7 @@ starts out at 1.
 This means that you can do
 
 ----------------
-$ git-read-tree -m <tree1> <tree2> <tree3>
+$ git read-tree -m <tree1> <tree2> <tree3>
 ----------------
 
 and you will end up with an index with all of the <tree1> entries in
@@ -261,7 +261,7 @@ start a 3-way merge with an index file that is already
 populated.  Here is an outline of how the algorithm works:
 
 - if a file exists in identical format in all three trees, it will
-  automatically collapse to "merged" state by git-read-tree.
+  automatically collapse to "merged" state by `git-read-tree`.
 
 - a file that has _any_ difference what-so-ever in the three trees
   will stay as separate entries in the index. It's up to "porcelain
@@ -304,16 +304,16 @@ commit.  To illustrate, suppose you start from what has been
 committed last to your repository:
 
 ----------------
-$ JC=`git-rev-parse --verify "HEAD^0"`
-$ git-checkout-index -f -u -a $JC
+$ JC=`git rev-parse --verify "HEAD^0"`
+$ git checkout-index -f -u -a $JC
 ----------------
 
-You do random edits, without running git-update-index.  And then
+You do random edits, without running `git-update-index`.  And then
 you notice that the tip of your "upstream" tree has advanced
 since you pulled from him:
 
 ----------------
-$ git-fetch git://.... linus
+$ git fetch git://.... linus
 $ LT=`cat .git/FETCH_HEAD`
 ----------------
 
@@ -323,10 +323,10 @@ added or modified index entries since $JC, and if you haven't,
 then does the right thing.  So with the following sequence:
 
 ----------------
-$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
-$ git-merge-index git-merge-one-file -a
+$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
+$ git merge-index git-merge-one-file -a
 $ echo "Merge with Linus" | \
-  git-commit-tree `git-write-tree` -p $JC -p $LT
+  git commit-tree `git write-tree` -p $JC -p $LT
 ----------------
 
 what you would commit is a pure merge between $JC and $LT without
@@ -334,7 +334,7 @@ your work-in-progress changes, and your work tree would be
 updated to the result of the merge.
 
 However, if you have local changes in the working tree that
-would be overwritten by this merge,`git-read-tree` will refuse
+would be overwritten by this merge, `git-read-tree` will refuse
 to run to prevent your changes from being lost.
 
 In other words, there is no need to worry about what exists only
diff --git a/git-rebase.html b/git-rebase.html
index c12560270..564948b37 100644
--- a/git-rebase.html
+++ b/git-rebase.html
@@ -273,15 +273,15 @@ git-rebase(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-rebase</em> [-i | --interactive] [-v | --verbose] [-m | --merge]
+<div class="content"><em>git rebase</em> [-i | --interactive] [-v | --verbose] [-m | --merge]
         [-s &lt;strategy&gt; | --strategy=&lt;strategy&gt;]
         [-C&lt;n&gt;] [ --whitespace=&lt;option&gt;] [-p | --preserve-merges]
         [--onto &lt;newbase&gt;] &lt;upstream&gt; [&lt;branch&gt;]
-<em>git-rebase</em> --continue | --skip | --abort</div></div>
+<em>git rebase</em> --continue | --skip | --abort</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>If &lt;branch&gt; is specified, git-rebase will perform an automatic
+<p>If &lt;branch&gt; is specified, <tt>git-rebase</tt> will perform an automatic
 <tt>git checkout &lt;branch&gt;</tt> before doing anything else.  Otherwise
 it remains on the current branch.</p>
 <p>All changes made by commits in the current branch but that are not
@@ -311,8 +311,8 @@ original &lt;branch&gt; and remove the .dotest working files, use the command
 <p>From this point, the result of either of the following commands:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-rebase master
-git-rebase master topic</tt></pre>
+<pre><tt>git rebase master
+git rebase master topic</tt></pre>
 </div></div>
 <p>would be:</p>
 <div class="listingblock">
@@ -325,7 +325,7 @@ git-rebase master topic</tt></pre>
 followed by <tt>git rebase master</tt>.</p>
 <p>If the upstream branch already contains a change you have made (e.g.,
 because you mailed a patch which was applied upstream), then that commit
-will be skipped. For example, running <tt>git-rebase master</tt> on the
+will be skipped. For example, running <tt>git rebase master</tt> on the
 following history (in which A' and A introduce the same set of changes,
 but have different committer information):</p>
 <div class="listingblock">
@@ -369,7 +369,7 @@ got merged into more stable <em>master</em> branch, like this:</p>
 <p>We can get this using the following command:</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-rebase --onto master next topic</tt></pre>
+<pre><tt>git rebase --onto master next topic</tt></pre>
 </div></div>
 <p>Another example of --onto option is to rebase part of a
 branch.  If we have the following situation:</p>
@@ -384,7 +384,7 @@ branch.  If we have the following situation:</p>
 <p>then the command</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-rebase --onto master topicA topicB</tt></pre>
+<pre><tt>git rebase --onto master topicA topicB</tt></pre>
 </div></div>
 <p>would result in:</p>
 <div class="listingblock">
@@ -405,7 +405,7 @@ the following situation:</p>
 <p>then the command</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-rebase --onto topicA~5 topicA~3 topicA</tt></pre>
+<pre><tt>git rebase --onto topicA~5 topicA~3 topicA</tt></pre>
 </div></div>
 <p>would result in the removal of commits F and G:</p>
 <div class="listingblock">
@@ -415,8 +415,8 @@ the following situation:</p>
 <p>This is useful if F and G were flawed in some way, or should not be
 part of topicA.  Note that the argument to --onto and the &lt;upstream&gt;
 parameter can be any valid commit-ish.</p>
-<p>In case of conflict, git-rebase will stop at the first problematic commit
-and leave conflict markers in the tree.  You can use git diff to locate
+<p>In case of conflict, <tt>git-rebase</tt> will stop at the first problematic commit
+and leave conflict markers in the tree.  You can use <tt>git-diff</tt> to locate
 the markers (&lt;&lt;&lt;&lt;&lt;&lt;) and make edits to resolve the conflict.  For each
 file you edit, you need to tell git that the conflict has been resolved,
 typically this would be done with</p>
@@ -430,7 +430,7 @@ desired resolution, you can continue the rebasing process with</p>
 <div class="content">
 <pre><tt>git rebase --continue</tt></pre>
 </div></div>
-<p>Alternatively, you can undo the git-rebase with</p>
+<p>Alternatively, you can undo the <tt>git-rebase</tt> with</p>
 <div class="literalblock">
 <div class="content">
 <pre><tt>git rebase --abort</tt></pre>
@@ -791,13 +791,13 @@ sure that the current HEAD is "B", and call</p>
 <h2>SPLITTING COMMITS</h2>
 <div class="sectionbody">
 <p>In interactive mode, you can mark commits with the action "edit".  However,
-this does not necessarily mean that <em>git rebase</em> expects the result of this
+this does not necessarily mean that <tt>git-rebase</tt> expects the result of this
 edit to be exactly one commit.  Indeed, you can undo the commit, or you can
 add other commits.  This can be used to split a commit into two:</p>
 <ul>
 <li>
 <p>
-Start an interactive rebase with <em>git rebase -i &lt;commit&gt;^</em>, where
+Start an interactive rebase with <tt>git rebase -i &lt;commit&gt;^</tt>, where
   &lt;commit&gt; is the commit you want to split.  In fact, any commit range
   will do, as long as it contains that commit.
 </p>
@@ -809,7 +809,7 @@ Mark the commit you want to split with the action "edit".
 </li>
 <li>
 <p>
-When it comes to editing that commit, execute <em>git reset HEAD^</em>.  The
+When it comes to editing that commit, execute <tt>git reset HEAD^</tt>.  The
   effect is that the HEAD is rewound by one, and the index follows suit.
   However, the working tree stays the same.
 </p>
@@ -817,8 +817,8 @@ When it comes to editing that commit, execute <em>git reset HEAD^</em>.  The
 <li>
 <p>
 Now add the changes to the index that you want to have in the first
-  commit.  You can use <a href="git-add.html">git-add(1)</a> (possibly interactively) and/or
-  <a href="git-gui.html">git-gui(1)</a> to do that.
+  commit.  You can use <tt>git add</tt> (possibly interactively) or
+  <tt>git-gui</tt> (or both) to do that.
 </p>
 </li>
 <li>
@@ -834,13 +834,13 @@ Repeat the last two steps until your working tree is clean.
 </li>
 <li>
 <p>
-Continue the rebase with <em>git rebase --continue</em>.
+Continue the rebase with <tt>git rebase --continue</tt>.
 </p>
 </li>
 </ul>
 <p>If you are not absolutely sure that the intermediate revisions are
 consistent (they compile, pass the testsuite, etc.) you should use
-<a href="git-stash.html">git-stash(1)</a> to stash away the not-yet-committed changes
+<tt>git-stash</tt> to stash away the not-yet-committed changes
 after each commit, test, and amend the commit if fixes are necessary.</p>
 </div>
 <h2>Authors</h2>
@@ -858,7 +858,7 @@ Johannes E. Schindelin &lt;johannes.schindelin@gmx.de&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:57 UTC
+Last updated 02-Jul-2008 03:01:57 UTC
 </div>
 </div>
 </body>
diff --git a/git-rebase.txt b/git-rebase.txt
index 716641435..754230e46 100644
--- a/git-rebase.txt
+++ b/git-rebase.txt
@@ -8,15 +8,15 @@ git-rebase - Forward-port local commits to the updated upstream head
 SYNOPSIS
 --------
 [verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
 	[-s <strategy> | --strategy=<strategy>]
 	[-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
 	[--onto <newbase>] <upstream> [<branch>]
-'git-rebase' --continue | --skip | --abort
+'git rebase' --continue | --skip | --abort
 
 DESCRIPTION
 -----------
-If <branch> is specified, git-rebase will perform an automatic
+If <branch> is specified, `git-rebase` will perform an automatic
 `git checkout <branch>` before doing anything else.  Otherwise
 it remains on the current branch.
 
@@ -52,8 +52,8 @@ Assume the following history exists and the current branch is "topic":
 From this point, the result of either of the following commands:
 
 
-    git-rebase master
-    git-rebase master topic
+    git rebase master
+    git rebase master topic
 
 would be:
 
@@ -68,7 +68,7 @@ followed by `git rebase master`.
 
 If the upstream branch already contains a change you have made (e.g.,
 because you mailed a patch which was applied upstream), then that commit
-will be skipped. For example, running `git-rebase master` on the
+will be skipped. For example, running `git rebase master` on the
 following history (in which A' and A introduce the same set of changes,
 but have different committer information):
 
@@ -116,7 +116,7 @@ got merged into more stable 'master' branch, like this:
 
 We can get this using the following command:
 
-    git-rebase --onto master next topic
+    git rebase --onto master next topic
 
 
 Another example of --onto option is to rebase part of a
@@ -132,7 +132,7 @@ branch.  If we have the following situation:
 
 then the command
 
-    git-rebase --onto master topicA topicB
+    git rebase --onto master topicA topicB
 
 would result in:
 
@@ -155,7 +155,7 @@ the following situation:
 
 then the command
 
-    git-rebase --onto topicA~5 topicA~3 topicA
+    git rebase --onto topicA~5 topicA~3 topicA
 
 would result in the removal of commits F and G:
 
@@ -167,8 +167,8 @@ This is useful if F and G were flawed in some way, or should not be
 part of topicA.  Note that the argument to --onto and the <upstream>
 parameter can be any valid commit-ish.
 
-In case of conflict, git-rebase will stop at the first problematic commit
-and leave conflict markers in the tree.  You can use git diff to locate
+In case of conflict, `git-rebase` will stop at the first problematic commit
+and leave conflict markers in the tree.  You can use `git-diff` to locate
 the markers (<<<<<<) and make edits to resolve the conflict.  For each
 file you edit, you need to tell git that the conflict has been resolved,
 typically this would be done with
@@ -184,7 +184,7 @@ desired resolution, you can continue the rebasing process with
     git rebase --continue
 
 
-Alternatively, you can undo the git-rebase with
+Alternatively, you can undo the `git-rebase` with
 
 
     git rebase --abort
@@ -364,34 +364,34 @@ SPLITTING COMMITS
 -----------------
 
 In interactive mode, you can mark commits with the action "edit".  However,
-this does not necessarily mean that 'git rebase' expects the result of this
+this does not necessarily mean that `git-rebase` expects the result of this
 edit to be exactly one commit.  Indeed, you can undo the commit, or you can
 add other commits.  This can be used to split a commit into two:
 
-- Start an interactive rebase with 'git rebase -i <commit>^', where
+- Start an interactive rebase with `git rebase -i <commit>^`, where
   <commit> is the commit you want to split.  In fact, any commit range
   will do, as long as it contains that commit.
 
 - Mark the commit you want to split with the action "edit".
 
-- When it comes to editing that commit, execute 'git reset HEAD^'.  The
+- When it comes to editing that commit, execute `git reset HEAD^`.  The
   effect is that the HEAD is rewound by one, and the index follows suit.
   However, the working tree stays the same.
 
 - Now add the changes to the index that you want to have in the first
-  commit.  You can use linkgit:git-add[1] (possibly interactively) and/or
-  linkgit:git-gui[1] to do that.
+  commit.  You can use `git add` (possibly interactively) or
+  `git-gui` (or both) to do that.
 
 - Commit the now-current index with whatever commit message is appropriate
   now.
 
 - Repeat the last two steps until your working tree is clean.
 
-- Continue the rebase with 'git rebase --continue'.
+- Continue the rebase with `git rebase --continue`.
 
 If you are not absolutely sure that the intermediate revisions are
 consistent (they compile, pass the testsuite, etc.) you should use
-linkgit:git-stash[1] to stash away the not-yet-committed changes
+`git-stash` to stash away the not-yet-committed changes
 after each commit, test, and amend the commit if fixes are necessary.
 
 
diff --git a/git-receive-pack.html b/git-receive-pack.html
index 17114544c..d5ea89b57 100644
--- a/git-receive-pack.html
+++ b/git-receive-pack.html
@@ -272,23 +272,23 @@ git-receive-pack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-receive-pack</em> &lt;directory&gt;</p>
+<p><em>git receive-pack</em> &lt;directory&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Invoked by <em>git-send-pack</em> and updates the repository with the
+<p>Invoked by <tt>git-send-pack</tt> and updates the repository with the
 information fed from the remote end.</p>
 <p>This command is usually not invoked directly by the end user.
-The UI for the protocol is on the <em>git-send-pack</em> side, and the
+The UI for the protocol is on the <tt>git-send-pack</tt> side, and the
 program pair is meant to be used to push updates to remote
-repository.  For pull operations, see <em>git-fetch-pack</em>.</p>
+repository.  For pull operations, see <a href="git-fetch-pack.html">git-fetch-pack(1)</a>.</p>
 <p>The command allows for creation and fast forwarding of sha1 refs
 (heads/tags) on the remote end (strictly speaking, it is the
-local end receive-pack runs, but to the user who is sitting at
+local end <tt>git-receive-pack</tt> runs, but to the user who is sitting at
 the send-pack end, it is updating the remote.  Confused?)</p>
 <p>There are other real-world examples of using update and
 post-update hooks found in the Documentation/howto directory.</p>
-<p>git-receive-pack honours the receive.denyNonFastForwards config
+<p><tt>git-receive-pack</tt> honours the receive.denyNonFastForwards config
 option, which tells it if updates to a ref should be denied if they
 are not fast-forwards.</p>
 </div>
@@ -378,10 +378,10 @@ do
         if expr "$oval" : '0*$' &gt;/dev/null
         then
                 echo "Created a new ref, with the following commits:"
-                git-rev-list --pretty "$nval"
+                git rev-list --pretty "$nval"
         else
                 echo "New commits:"
-                git-rev-list --pretty "$nval" "^$oval"
+                git rev-list --pretty "$nval" "^$oval"
         fi |
         mail -s "Changes to ref $ref" commit-list@mydomain
 done
@@ -391,7 +391,7 @@ exit 0</tt></pre>
 non-zero exit code will generate an error message.</p>
 <p>Note that it is possible for refname to not have sha1-new when this
 hook runs.  This can easily occur if another user modifies the ref
-after it was updated by receive-pack, but before the hook was able
+after it was updated by <tt>git-receive-pack</tt>, but before the hook was able
 to evaluate it.  It is recommended that hooks rely on sha1-new
 rather than the current value of refname.</p>
 </div>
@@ -402,14 +402,14 @@ if $GIT_DIR/hooks/post-update file exists and is executable, then
 post-update will called with the list of refs that have been updated.
 This can be used to implement any repository wide cleanup tasks.</p>
 <p>The exit code from this hook invocation is ignored; the only thing
-left for git-receive-pack to do at that point is to exit itself
+left for <tt>git-receive-pack</tt> to do at that point is to exit itself
 anyway.</p>
-<p>This hook can be used, for example, to run "git-update-server-info"
+<p>This hook can be used, for example, to run <tt>git update-server-info</tt>
 if the repository is packed and is served via a dumb transport.</p>
 <div class="literalblock">
 <div class="content">
 <pre><tt>#!/bin/sh
-exec git-update-server-info</tt></pre>
+exec git update-server-info</tt></pre>
 </div></div>
 </div>
 <h2>SEE ALSO</h2>
@@ -430,7 +430,7 @@ exec git-update-server-info</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:03 UTC
+Last updated 02-Jul-2008 03:01:58 UTC
 </div>
 </div>
 </body>
diff --git a/git-receive-pack.txt b/git-receive-pack.txt
index a70c7168f..207684d1c 100644
--- a/git-receive-pack.txt
+++ b/git-receive-pack.txt
@@ -8,27 +8,27 @@ git-receive-pack - Receive what is pushed into the repository
 
 SYNOPSIS
 --------
-'git-receive-pack' <directory>
+'git receive-pack' <directory>
 
 DESCRIPTION
 -----------
-Invoked by 'git-send-pack' and updates the repository with the
+Invoked by `git-send-pack` and updates the repository with the
 information fed from the remote end.
 
 This command is usually not invoked directly by the end user.
-The UI for the protocol is on the 'git-send-pack' side, and the
+The UI for the protocol is on the `git-send-pack` side, and the
 program pair is meant to be used to push updates to remote
-repository.  For pull operations, see 'git-fetch-pack'.
+repository.  For pull operations, see linkgit:git-fetch-pack[1].
 
 The command allows for creation and fast forwarding of sha1 refs
 (heads/tags) on the remote end (strictly speaking, it is the
-local end receive-pack runs, but to the user who is sitting at
+local end `git-receive-pack` runs, but to the user who is sitting at
 the send-pack end, it is updating the remote.  Confused?)
 
 There are other real-world examples of using update and
 post-update hooks found in the Documentation/howto directory.
 
-git-receive-pack honours the receive.denyNonFastForwards config
+`git-receive-pack` honours the receive.denyNonFastForwards config
 option, which tells it if updates to a ref should be denied if they
 are not fast-forwards.
 
@@ -111,10 +111,10 @@ ref listing the commits pushed to the repository:
 		if expr "$oval" : '0*$' >/dev/null
 		then
 			echo "Created a new ref, with the following commits:"
-			git-rev-list --pretty "$nval"
+			git rev-list --pretty "$nval"
 		else
 			echo "New commits:"
-			git-rev-list --pretty "$nval" "^$oval"
+			git rev-list --pretty "$nval" "^$oval"
 		fi |
 		mail -s "Changes to ref $ref" commit-list@mydomain
 	done
@@ -125,7 +125,7 @@ non-zero exit code will generate an error message.
 
 Note that it is possible for refname to not have sha1-new when this
 hook runs.  This can easily occur if another user modifies the ref
-after it was updated by receive-pack, but before the hook was able
+after it was updated by `git-receive-pack`, but before the hook was able
 to evaluate it.  It is recommended that hooks rely on sha1-new
 rather than the current value of refname.
 
@@ -137,14 +137,14 @@ post-update will called with the list of refs that have been updated.
 This can be used to implement any repository wide cleanup tasks.
 
 The exit code from this hook invocation is ignored; the only thing
-left for git-receive-pack to do at that point is to exit itself
+left for `git-receive-pack` to do at that point is to exit itself
 anyway.
 
-This hook can be used, for example, to run "git-update-server-info"
+This hook can be used, for example, to run `git update-server-info`
 if the repository is packed and is served via a dumb transport.
 
 	#!/bin/sh
-	exec git-update-server-info
+	exec git update-server-info
 
 
 SEE ALSO
diff --git a/git-reflog.html b/git-reflog.html
index 327c6cb87..8fb049cc1 100644
--- a/git-reflog.html
+++ b/git-reflog.html
@@ -397,7 +397,7 @@ them.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:03 UTC
+Last updated 02-Jul-2008 03:01:58 UTC
 </div>
 </div>
 </body>
diff --git a/git-relink.html b/git-relink.html
index 47c8441c6..48c9ea4e9 100644
--- a/git-relink.html
+++ b/git-relink.html
@@ -272,7 +272,7 @@ git-relink(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-relink</em> [--safe] &lt;dir&gt; [&lt;dir&gt;]* &lt;master_dir&gt;</p>
+<p><em>git relink</em> [--safe] &lt;dir&gt; [&lt;dir&gt;]* &lt;master_dir&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -316,7 +316,7 @@ repository will be replaced with a hardlink to the master repository.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:04 UTC
+Last updated 02-Jul-2008 03:01:58 UTC
 </div>
 </div>
 </body>
diff --git a/git-relink.txt b/git-relink.txt
index f6dafd449..25ff8f9dc 100644
--- a/git-relink.txt
+++ b/git-relink.txt
@@ -7,7 +7,7 @@ git-relink - Hardlink common objects in local repositories
 
 SYNOPSIS
 --------
-'git-relink' [--safe] <dir> [<dir>]\* <master_dir>
+'git relink' [--safe] <dir> [<dir>]\* <master_dir>
 
 DESCRIPTION
 -----------
diff --git a/git-remote.html b/git-remote.html
index 1df4bbf72..d18790184 100644
--- a/git-remote.html
+++ b/git-remote.html
@@ -273,12 +273,12 @@ git-remote(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-remote</em> [-v | --verbose]
-<em>git-remote</em> add [-t &lt;branch&gt;] [-m &lt;master&gt;] [-f] [--mirror] &lt;name&gt; &lt;url&gt;
-<em>git-remote</em> rm &lt;name&gt;
-<em>git-remote</em> show [-n] &lt;name&gt;
-<em>git-remote</em> prune [-n | --dry-run] &lt;name&gt;
-<em>git-remote</em> update [group]</div></div>
+<div class="content"><em>git remote</em> [-v | --verbose]
+<em>git remote</em> add [-t &lt;branch&gt;] [-m &lt;master&gt;] [-f] [--mirror] &lt;name&gt; &lt;url&gt;
+<em>git remote</em> rm &lt;name&gt;
+<em>git remote</em> show [-n] &lt;name&gt;
+<em>git remote</em> prune [-n | --dry-run] &lt;name&gt;
+<em>git remote</em> update [group]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -445,7 +445,7 @@ $ git merge origin</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:42 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-remote.txt b/git-remote.txt
index 345943a26..32db0aed1 100644
--- a/git-remote.txt
+++ b/git-remote.txt
@@ -9,12 +9,12 @@ git-remote - manage set of tracked repositories
 SYNOPSIS
 --------
 [verse]
-'git-remote' [-v | --verbose]
-'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
-'git-remote' rm <name>
-'git-remote' show [-n] <name>
-'git-remote' prune [-n | --dry-run] <name>
-'git-remote' update [group]
+'git remote' [-v | --verbose]
+'git remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote' rm <name>
+'git remote' show [-n] <name>
+'git remote' prune [-n | --dry-run] <name>
+'git remote' update [group]
 
 DESCRIPTION
 -----------
diff --git a/git-repack.html b/git-repack.html
index b6dab0982..c2c792ebb 100644
--- a/git-repack.html
+++ b/git-repack.html
@@ -272,7 +272,7 @@ git-repack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-repack</em> [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]</p>
+<p><em>git repack</em> [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -317,7 +317,7 @@ engines, disk storage, etc.</p>
         deleted by way of being left in the old pack and then
         removed.  Instead, the loose unreachable objects
         will be pruned according to normal expiry rules
-        with the next <a href="git-gc.html">git-gc(1)</a>.
+        with the next <tt>git-gc</tt> invocation. See <a href="git-gc.html">git-gc(1)</a>.
 </p>
 </dd>
 <dt>
@@ -327,7 +327,8 @@ engines, disk storage, etc.</p>
 <p>
         After packing, if the newly created packs make some
         existing packs redundant, remove the redundant packs.
-        Also runs <a href="git-prune-packed.html">git-prune-packed(1)</a>.
+        Also run  <tt>git-prune-packed</tt> to remove redundant
+        loose object files.
 </p>
 </dd>
 <dt>
@@ -335,7 +336,7 @@ engines, disk storage, etc.</p>
 </dt>
 <dd>
 <p>
-        Pass the <tt>--local</tt> option to <tt>git pack-objects</tt>, see
+        Pass the <tt>--local</tt> option to <tt>git-pack-objects</tt>. See
         <a href="git-pack-objects.html">git-pack-objects(1)</a>.
 </p>
 </dd>
@@ -344,7 +345,7 @@ engines, disk storage, etc.</p>
 </dt>
 <dd>
 <p>
-        Pass the <tt>--no-reuse-delta</tt> option to <tt>git pack-objects</tt>, see
+        Pass the <tt>--no-reuse-delta</tt> option to <tt>git-pack-objects</tt>. See
         <a href="git-pack-objects.html">git-pack-objects(1)</a>.
 </p>
 </dd>
@@ -353,7 +354,7 @@ engines, disk storage, etc.</p>
 </dt>
 <dd>
 <p>
-        Pass the <tt>-q</tt> option to <tt>git pack-objects</tt>, see
+        Pass the <tt>-q</tt> option to <tt>git-pack-objects</tt>. See
         <a href="git-pack-objects.html">git-pack-objects(1)</a>.
 </p>
 </dd>
@@ -363,7 +364,7 @@ engines, disk storage, etc.</p>
 <dd>
 <p>
         Do not update the server information with
-        <tt>git update-server-info</tt>.  This option skips
+        <tt>git-update-server-info</tt>.  This option skips
         updating local catalog files needed to publish
         this repository (or a direct copy of it)
         over HTTP or FTP.  See .
@@ -446,7 +447,7 @@ that way can try to use older git with it).</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:58 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-repack.txt b/git-repack.txt
index 04d6f1fbc..0d72e8302 100644
--- a/git-repack.txt
+++ b/git-repack.txt
@@ -8,7 +8,7 @@ git-repack - Pack unpacked objects in a repository
 
 SYNOPSIS
 --------
-'git-repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
+'git repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
 
 DESCRIPTION
 -----------
@@ -47,28 +47,29 @@ OPTIONS
 	deleted by way of being left in the old pack and then
 	removed.  Instead, the loose unreachable objects
 	will be pruned according to normal expiry rules
-	with the next linkgit:git-gc[1].
+	with the next `git-gc` invocation. See linkgit:git-gc[1].
 
 -d::
 	After packing, if the newly created packs make some
 	existing packs redundant, remove the redundant packs.
-	Also runs linkgit:git-prune-packed[1].
+	Also run  `git-prune-packed` to remove redundant
+	loose object files.
 
 -l::
-        Pass the `--local` option to `git pack-objects`, see
+	Pass the `--local` option to `git-pack-objects`. See
 	linkgit:git-pack-objects[1].
 
 -f::
-        Pass the `--no-reuse-delta` option to `git pack-objects`, see
+	Pass the `--no-reuse-delta` option to `git-pack-objects`. See
 	linkgit:git-pack-objects[1].
 
 -q::
-        Pass the `-q` option to `git pack-objects`, see
+	Pass the `-q` option to `git-pack-objects`. See
 	linkgit:git-pack-objects[1].
 
 -n::
 	Do not update the server information with
-	`git update-server-info`.  This option skips
+	`git-update-server-info`.  This option skips
 	updating local catalog files needed to publish
 	this repository (or a direct copy of it)
 	over HTTP or FTP.  See gitlink:git-update-server-info[1].
diff --git a/git-repo-config.html b/git-repo-config.html
index 618b247ff..6a5ec6652 100644
--- a/git-repo-config.html
+++ b/git-repo-config.html
@@ -272,7 +272,7 @@ git-repo-config(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-repo-config</em> &#8230;</p>
+<p><em>git repo-config</em> &#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,7 +281,7 @@ documentation of that command.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:05 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-repo-config.txt b/git-repo-config.txt
index 2ca39946b..e5bdb5533 100644
--- a/git-repo-config.txt
+++ b/git-repo-config.txt
@@ -8,7 +8,7 @@ git-repo-config - Get and set repository or global options
 
 SYNOPSIS
 --------
-'git-repo-config' ...
+'git repo-config' ...
 
 
 DESCRIPTION
diff --git a/git-request-pull.html b/git-request-pull.html
index cf102690c..0ef5cf2d3 100644
--- a/git-request-pull.html
+++ b/git-request-pull.html
@@ -272,7 +272,7 @@ git-request-pull(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-request-pull</em> &lt;start&gt; &lt;url&gt; [&lt;end&gt;]</p>
+<p><em>git request-pull</em> &lt;start&gt; &lt;url&gt; [&lt;end&gt;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -322,7 +322,7 @@ the given URL in the generated summary.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:06 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-request-pull.txt b/git-request-pull.txt
index c71d86985..ca6843032 100644
--- a/git-request-pull.txt
+++ b/git-request-pull.txt
@@ -7,7 +7,7 @@ git-request-pull - Generates a summary of pending changes
 
 SYNOPSIS
 --------
-'git-request-pull' <start> <url> [<end>]
+'git request-pull' <start> <url> [<end>]
 
 DESCRIPTION
 -----------
diff --git a/git-rerere.html b/git-rerere.html
index 136ec0c0d..fab9d72ec 100644
--- a/git-rerere.html
+++ b/git-rerere.html
@@ -272,7 +272,7 @@ git-rerere(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-rerere</em> [clear|diff|status|gc]</p>
+<p><em>git rerere</em> [clear|diff|status|gc]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -296,7 +296,7 @@ enable this command.</td>
 </div>
 <h2>COMMANDS</h2>
 <div class="sectionbody">
-<p>Normally, git-rerere is run without arguments or user-intervention.
+<p>Normally, <tt>git-rerere</tt> is run without arguments or user-intervention.
 However, it has several commands that allow it to interact with
 its working state.</p>
 <dl>
@@ -306,8 +306,8 @@ its working state.</p>
 <dd>
 <p>
 This resets the metadata used by rerere if a merge resolution is to be
-is aborted.  Calling <a href="git-am.html">git-am(1)</a> --skip or <a href="git-rebase.html">git-rebase(1)</a>
-[--skip|--abort] will automatically invoke this command.
+is aborted.  Calling <tt>git-am --skip</tt> or <tt>git-rebase [--skip|--abort]</tt>
+will automatically invoke this command.
 </p>
 </dd>
 <dt>
@@ -318,7 +318,7 @@ is aborted.  Calling <a href="git-am.html">git-am(1)</a> --skip or <a href="git-
 This displays diffs for the current state of the resolution.  It is
 useful for tracking what has changed while the user is resolving
 conflicts.  Additional arguments are passed directly to the system
-diff(1) command installed in PATH.
+<tt>diff</tt> command installed in PATH.
 </p>
 </dd>
 <dt>
@@ -421,7 +421,7 @@ same conflict you resolved when you created the test merge you
 blew away.  <tt>git-rerere</tt> command helps you to resolve this final
 conflicted merge using the information from your earlier hand
 resolve.</p>
-<p>Running <tt>git-rerere</tt> command immediately after a conflicted
+<p>Running the <tt>git-rerere</tt> command immediately after a conflicted
 automerge records the conflicted working tree files, with the
 usual conflict markers <tt>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</tt>, <tt>=======</tt>, and <tt>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</tt> in
 them.  Later, after you are done resolving the conflicts,
@@ -468,7 +468,7 @@ development on the topic branch:</p>
 up-to-date even before your topic is ready to be sent upstream.
 This would result in falling back to three-way merge, and it
 would conflict the same way the test merge you resolved earlier.
-<tt>git-rerere</tt> is run by <tt>git rebase</tt> to help you resolve this
+<tt>git-rerere</tt> is run by <tt>git-rebase</tt> to help you resolve this
 conflict.</p>
 </div>
 <h2>Author</h2>
@@ -481,7 +481,7 @@ conflict.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:06 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-rerere.txt b/git-rerere.txt
index 8030ec4d0..345802904 100644
--- a/git-rerere.txt
+++ b/git-rerere.txt
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
-'git-rerere' [clear|diff|status|gc]
+'git rerere' [clear|diff|status|gc]
 
 DESCRIPTION
 -----------
@@ -30,22 +30,22 @@ enable this command.
 COMMANDS
 --------
 
-Normally, git-rerere is run without arguments or user-intervention.
+Normally, `git-rerere` is run without arguments or user-intervention.
 However, it has several commands that allow it to interact with
 its working state.
 
 'clear'::
 
 This resets the metadata used by rerere if a merge resolution is to be
-is aborted.  Calling linkgit:git-am[1] --skip or linkgit:git-rebase[1]
-[--skip|--abort] will automatically invoke this command.
+is aborted.  Calling `git-am --skip` or `git-rebase [--skip|--abort]`
+will automatically invoke this command.
 
 'diff'::
 
 This displays diffs for the current state of the resolution.  It is
 useful for tracking what has changed while the user is resolving
 conflicts.  Additional arguments are passed directly to the system
-diff(1) command installed in PATH.
+`diff` command installed in PATH.
 
 'status'::
 
@@ -146,7 +146,7 @@ blew away.  `git-rerere` command helps you to resolve this final
 conflicted merge using the information from your earlier hand
 resolve.
 
-Running `git-rerere` command immediately after a conflicted
+Running the `git-rerere` command immediately after a conflicted
 automerge records the conflicted working tree files, with the
 usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
 them.  Later, after you are done resolving the conflicts,
@@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
 up-to-date even before your topic is ready to be sent upstream.
 This would result in falling back to three-way merge, and it
 would conflict the same way the test merge you resolved earlier.
-`git-rerere` is run by `git rebase` to help you resolve this
+`git-rerere` is run by `git-rebase` to help you resolve this
 conflict.
 
 
diff --git a/git-reset.html b/git-reset.html
index da17b8717..dde5e3248 100644
--- a/git-reset.html
+++ b/git-reset.html
@@ -308,7 +308,7 @@ the index from a given commit, without moving HEAD.</p>
 <p>
         Does not touch the index file nor the working tree at all, but
         requires them to be in a good order. This leaves all your changed
-        files "Changes to be committed", as <a href="git-status.html">git-status(1)</a> would
+        files "Changes to be committed", as <tt>git-status</tt> would
         put it.
 </p>
 </dd>
@@ -607,7 +607,7 @@ Adds the file to the index again.
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:07 UTC
+Last updated 02-Jul-2008 03:01:59 UTC
 </div>
 </div>
 </body>
diff --git a/git-reset.txt b/git-reset.txt
index 12ea9b23c..dc05f58f1 100644
--- a/git-reset.txt
+++ b/git-reset.txt
@@ -37,7 +37,7 @@ OPTIONS
 --soft::
 	Does not touch the index file nor the working tree at all, but
 	requires them to be in a good order. This leaves all your changed
-	files "Changes to be committed", as linkgit:git-status[1] would
+	files "Changes to be committed", as `git-status` would
 	put it.
 
 --hard::
diff --git a/git-rev-list.html b/git-rev-list.html
index b26b4e34b..5a94c9116 100644
--- a/git-rev-list.html
+++ b/git-rev-list.html
@@ -321,7 +321,7 @@ stop at that point. Their parents are implied. Thus the following
 command:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        $ git-rev-list foo bar ^baz</tt></pre>
+<pre><tt>        $ git rev-list foo bar ^baz</tt></pre>
 </div></div>
 <p>means "list all the commits which are included in <em>foo</em> and <em>bar</em>, but
 not in <em>baz</em>".</p>
@@ -330,22 +330,22 @@ short-hand for "&#94;<em>&lt;commit1&gt;</em> <em>&lt;commit2&gt;</em>". For exa
 the following may be used interchangeably:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        $ git-rev-list origin..HEAD
-        $ git-rev-list HEAD ^origin</tt></pre>
+<pre><tt>        $ git rev-list origin..HEAD
+        $ git rev-list HEAD ^origin</tt></pre>
 </div></div>
 <p>Another special notation is "<em>&lt;commit1&gt;</em>&#8230;<em>&lt;commit2&gt;</em>" which is useful
 for merges.  The resulting set of commits is the symmetric difference
 between the two operands.  The following two commands are equivalent:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        $ git-rev-list A B --not $(git-merge-base --all A B)
-        $ git-rev-list A...B</tt></pre>
+<pre><tt>        $ git rev-list A B --not $(git merge-base --all A B)
+        $ git rev-list A...B</tt></pre>
 </div></div>
-<p><a href="git-rev-list.html">git-rev-list(1)</a> is a very essential git program, since it
+<p><tt>git-rev-list</tt> is a very essential git program, since it
 provides the ability to build and traverse commit ancestry graphs. For
 this reason, it has a lot of different options that enables it to be
-used by commands as different as <a href="git-bisect.html">git-bisect(1)</a> and
-<a href="git-repack.html">git-repack(1)</a>.</p>
+used by commands as different as <tt>git-bisect</tt> and
+<tt>git-repack</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -1279,7 +1279,7 @@ and the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:43 UTC
+Last updated 02-Jul-2008 03:02:00 UTC
 </div>
 </div>
 </body>
diff --git a/git-rev-list.txt b/git-rev-list.txt
index c9b095032..e7d736ffa 100644
--- a/git-rev-list.txt
+++ b/git-rev-list.txt
@@ -59,7 +59,7 @@ stop at that point. Their parents are implied. Thus the following
 command:
 
 -----------------------------------------------------------------------
-	$ git-rev-list foo bar ^baz
+	$ git rev-list foo bar ^baz
 -----------------------------------------------------------------------
 
 means "list all the commits which are included in 'foo' and 'bar', but
@@ -70,8 +70,8 @@ short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
 the following may be used interchangeably:
 
 -----------------------------------------------------------------------
-	$ git-rev-list origin..HEAD
-	$ git-rev-list HEAD ^origin
+	$ git rev-list origin..HEAD
+	$ git rev-list HEAD ^origin
 -----------------------------------------------------------------------
 
 Another special notation is "'<commit1>'...'<commit2>'" which is useful
@@ -79,15 +79,15 @@ for merges.  The resulting set of commits is the symmetric difference
 between the two operands.  The following two commands are equivalent:
 
 -----------------------------------------------------------------------
-	$ git-rev-list A B --not $(git-merge-base --all A B)
-	$ git-rev-list A...B
+	$ git rev-list A B --not $(git merge-base --all A B)
+	$ git rev-list A...B
 -----------------------------------------------------------------------
 
-linkgit:git-rev-list[1] is a very essential git program, since it
+`git-rev-list` is a very essential git program, since it
 provides the ability to build and traverse commit ancestry graphs. For
 this reason, it has a lot of different options that enables it to be
-used by commands as different as linkgit:git-bisect[1] and
-linkgit:git-repack[1].
+used by commands as different as `git-bisect` and
+`git-repack`.
 
 OPTIONS
 -------
diff --git a/git-rev-parse.html b/git-rev-parse.html
index eb27abbff..0286d4fa9 100644
--- a/git-rev-parse.html
+++ b/git-rev-parse.html
@@ -272,14 +272,14 @@ git-rev-parse(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-rev-parse</em> [ --option ] &lt;args&gt;&#8230;</p>
+<p><em>git rev-parse</em> [ --option ] &lt;args&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Many git porcelainish commands take mixture of flags
 (i.e. parameters that begin with a dash <em>-</em>) and parameters
-meant for underlying <tt>git-rev-list</tt> command they use internally
-and flags and parameters for other commands they use as the
+meant for the underlying <tt>git-rev-list</tt> command they use internally
+and flags and parameters for the other commands they use
 downstream of <tt>git-rev-list</tt>.  This command is used to
 distinguish between them.</p>
 </div>
@@ -521,8 +521,8 @@ distinguish between them.</p>
 </dt>
 <dd>
 <p>
-        Parses the date string, and outputs corresponding
-        --max-age= parameter for git-rev-list command.
+        Parse the date string, and output the corresponding
+        --max-age= parameter for <tt>git-rev-list</tt>.
 </p>
 </dd>
 <dt>
@@ -533,8 +533,8 @@ distinguish between them.</p>
 </dt>
 <dd>
 <p>
-        Parses the date string, and outputs corresponding
-        --min-age= parameter for git-rev-list command.
+        Parse the date string, and output the corresponding
+        --min-age= parameter for <tt>git-rev-list</tt>.
 </p>
 </dd>
 <dt>
@@ -759,7 +759,7 @@ reachable from <tt>r1</tt> from the set of commits reachable from
 <tt>r2</tt>).</p>
 <p>A similar notation "<tt>r1...r2</tt>" is called symmetric difference
 of <tt>r1</tt> and <tt>r2</tt> and is defined as
-"<tt>r1 r2 --not $(git-merge-base --all r1 r2)</tt>".
+"<tt>r1 r2 --not $(git merge-base --all r1 r2)</tt>".
 It is the set of commits that are reachable from either one of
 <tt>r1</tt> or <tt>r2</tt> but not from both.</p>
 <p>Two other shorthands for naming a set that is formed by a commit
@@ -864,7 +864,7 @@ bar=      some cool option --bar with an argument
   An option group Header
 C?        option C with an optional argument"
 
-eval `echo "$OPTS_SPEC" | git-rev-parse --parseopt -- "$@" || echo exit $?`</tt></pre>
+eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`</tt></pre>
 </div></div>
 </div>
 <h2>EXAMPLES</h2>
@@ -916,7 +916,7 @@ Junio C Hamano &lt;junkio@cox.net&gt; and Pierre Habouzit &lt;madcoder@debian.or
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 30-Jun-2008 09:04:38 UTC
+Last updated 02-Jul-2008 03:02:00 UTC
 </div>
 </div>
 </body>
diff --git a/git-rev-parse.txt b/git-rev-parse.txt
index 59e95adf4..6825ae27c 100644
--- a/git-rev-parse.txt
+++ b/git-rev-parse.txt
@@ -8,15 +8,15 @@ git-rev-parse - Pick out and massage parameters
 
 SYNOPSIS
 --------
-'git-rev-parse' [ --option ] <args>...
+'git rev-parse' [ --option ] <args>...
 
 DESCRIPTION
 -----------
 
 Many git porcelainish commands take mixture of flags
 (i.e. parameters that begin with a dash '-') and parameters
-meant for underlying `git-rev-list` command they use internally
-and flags and parameters for other commands they use as the
+meant for the underlying `git-rev-list` command they use internally
+and flags and parameters for the other commands they use
 downstream of `git-rev-list`.  This command is used to
 distinguish between them.
 
@@ -128,13 +128,13 @@ OPTIONS
 
 --since=datestring::
 --after=datestring::
-	Parses the date string, and outputs corresponding
-	--max-age= parameter for git-rev-list command.
+	Parse the date string, and output the corresponding
+	--max-age= parameter for `git-rev-list`.
 
 --until=datestring::
 --before=datestring::
-	Parses the date string, and outputs corresponding
-	--min-age= parameter for git-rev-list command.
+	Parse the date string, and output the corresponding
+	--min-age= parameter for `git-rev-list`.
 
 <args>...::
 	Flags and parameters to be parsed.
@@ -296,7 +296,7 @@ reachable from `r1` from the set of commits reachable from
 
 A similar notation "`r1\...r2`" is called symmetric difference
 of `r1` and `r2` and is defined as
-"`r1 r2 --not $(git-merge-base --all r1 r2)`".
+"`r1 r2 --not $(git merge-base --all r1 r2)`".
 It is the set of commits that are reachable from either one of
 `r1` or `r2` but not from both.
 
@@ -384,7 +384,7 @@ bar=      some cool option --bar with an argument
   An option group Header
 C?        option C with an optional argument"
 
-eval `echo "$OPTS_SPEC" | git-rev-parse --parseopt -- "$@" || echo exit $?`
+eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
 ------------
 
 EXAMPLES
diff --git a/git-revert.html b/git-revert.html
index 0766f143d..77d378b2e 100644
--- a/git-revert.html
+++ b/git-revert.html
@@ -272,7 +272,7 @@ git-revert(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-revert</em> [--edit | --no-edit] [-n] [-m parent-number] [-s] &lt;commit&gt;</p>
+<p><em>git revert</em> [--edit | --no-edit] [-n] [-m parent-number] [-s] &lt;commit&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -377,7 +377,7 @@ effect to your working tree in a row.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:46:58 UTC
+Last updated 02-Jul-2008 03:02:00 UTC
 </div>
 </div>
 </body>
diff --git a/git-revert.txt b/git-revert.txt
index 5b49b8138..3d0c5aba9 100644
--- a/git-revert.txt
+++ b/git-revert.txt
@@ -7,7 +7,7 @@ git-revert - Revert an existing commit
 
 SYNOPSIS
 --------
-'git-revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
+'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
 
 DESCRIPTION
 -----------
diff --git a/git-rm.html b/git-rm.html
index ceac28720..74798cb64 100644
--- a/git-rm.html
+++ b/git-rm.html
@@ -272,12 +272,12 @@ git-rm(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-rm</em> [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] &lt;file&gt;&#8230;</p>
+<p><em>git rm</em> [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] &lt;file&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Remove files from the index, or from the working tree and the index.
-<tt>git rm</tt> will not remove a file from just your working directory.
+<tt>git-rm</tt> will not remove a file from just your working directory.
 (There is no option to remove a file only from the work tree
 and yet keep it in the index; use <tt>/bin/rm</tt> if you want to do that.)
 The files being removed have to be identical to the tip of the branch,
@@ -371,7 +371,7 @@ allowing the file to be removed from just the index.</p>
 </dt>
 <dd>
 <p>
-        git-rm normally outputs one line (in the form of an "rm" command)
+        <tt>git-rm</tt> normally outputs one line (in the form of an "rm" command)
         for each file removed. This option suppresses that output.
 </p>
 </dd>
@@ -392,7 +392,7 @@ also remove all of directory <tt>d2</tt>.</p>
 <div class="sectionbody">
 <dl>
 <dt>
-git-rm Documentation/\*.txt
+git rm Documentation/\*.txt
 </dt>
 <dd>
 <p>
@@ -404,7 +404,7 @@ example; this lets git, and not the shell, expand the pathnames
 of files and subdirectories under the <tt>Documentation/</tt> directory.</p>
 </dd>
 <dt>
-git-rm -f git-*.sh
+git rm -f git-*.sh
 </dt>
 <dd>
 <p>
@@ -433,7 +433,7 @@ git-rm -f git-*.sh
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:00 UTC
+Last updated 02-Jul-2008 03:02:01 UTC
 </div>
 </div>
 </body>
diff --git a/git-rm.txt b/git-rm.txt
index d88554bed..01b63be38 100644
--- a/git-rm.txt
+++ b/git-rm.txt
@@ -7,12 +7,12 @@ git-rm - Remove files from the working tree and from the index
 
 SYNOPSIS
 --------
-'git-rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
+'git rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
 
 DESCRIPTION
 -----------
 Remove files from the index, or from the working tree and the index.
-`git rm` will not remove a file from just your working directory.
+`git-rm` will not remove a file from just your working directory.
 (There is no option to remove a file only from the work tree
 and yet keep it in the index; use `/bin/rm` if you want to do that.)
 The files being removed have to be identical to the tip of the branch,
@@ -63,7 +63,7 @@ OPTIONS
 
 -q::
 --quiet::
-	git-rm normally outputs one line (in the form of an "rm" command)
+	`git-rm` normally outputs one line (in the form of an "rm" command)
 	for each file removed. This option suppresses that output.
 
 
@@ -82,7 +82,7 @@ also remove all of directory `d2`.
 
 EXAMPLES
 --------
-git-rm Documentation/\\*.txt::
+git rm Documentation/\\*.txt::
 	Removes all `\*.txt` files from the index that are under the
 	`Documentation` directory and any of its subdirectories.
 +
@@ -90,7 +90,7 @@ Note that the asterisk `\*` is quoted from the shell in this
 example; this lets git, and not the shell, expand the pathnames
 of files and subdirectories under the `Documentation/` directory.
 
-git-rm -f git-*.sh::
+git rm -f git-*.sh::
 	Because this example lets the shell expand the asterisk
 	(i.e. you are listing the files explicitly), it
 	does not remove `subdir/git-foo.sh`.
diff --git a/git-send-email.html b/git-send-email.html
index 934d29496..d92f086d5 100644
--- a/git-send-email.html
+++ b/git-send-email.html
@@ -272,7 +272,7 @@ git-send-email(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-send-email</em> [options] &lt;file|directory&gt; [&#8230; file|directory]</p>
+<p><em>git send-email</em> [options] &lt;file|directory&gt; [&#8230; file|directory]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -476,13 +476,21 @@ specified (with --smtp-pass or a configuration variable), then the
 user is prompted for a password while the input is masked for privacy.</p>
 </dd>
 <dt>
+--smtp-encryption
+</dt>
+<dd>
+<p>
+        Specify the encryption to use, either <em>ssl</em> or <em>tls</em>.  Any other
+        value reverts to plain SMTP.  Default is the value of
+        <em>sendemail.smtpencryption</em>.
+</p>
+</dd>
+<dt>
 --smtp-ssl
 </dt>
 <dd>
 <p>
-        If set, connects to the SMTP server using SSL.
-        Default is the value of the <em>sendemail.smtpssl</em> configuration value;
-        if that is unspecified, does not use SSL.
+        Legacy alias for <em>--smtp-encryption=ssl</em>.
 </p>
 </dd>
 <dt>
@@ -672,11 +680,21 @@ sendemail.smtppass
 </p>
 </dd>
 <dt>
+sendemail.smtpencryption
+</dt>
+<dd>
+<p>
+        Default encryption method.  Use <em>ssl</em> for SSL (and specify an
+        appropriate port), or <em>tls</em> for TLS.  Takes precedence over
+        <em>smtpssl</em> if both are specified.
+</p>
+</dd>
+<dt>
 sendemail.smtpssl
 </dt>
 <dd>
 <p>
-        Boolean value specifying the default to the <em>--smtp-ssl</em> parameter.
+        Legacy boolean that sets <em>smtpencryption=ssl</em> if enabled.
 </p>
 </dd>
 </dl>
@@ -697,7 +715,7 @@ send_lots_of_email.pl by Greg Kroah-Hartman.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:00 UTC
+Last updated 02-Jul-2008 03:02:01 UTC
 </div>
 </div>
 </body>
diff --git a/git-send-email.txt b/git-send-email.txt
index 251d661af..afbb294a7 100644
--- a/git-send-email.txt
+++ b/git-send-email.txt
@@ -8,7 +8,7 @@ git-send-email - Send a collection of patches as emails
 
 SYNOPSIS
 --------
-'git-send-email' [options] <file|directory> [... file|directory]
+'git send-email' [options] <file|directory> [... file|directory]
 
 
 
@@ -133,10 +133,13 @@ or on the command line. If a username has been specified (with
 specified (with --smtp-pass or a configuration variable), then the
 user is prompted for a password while the input is masked for privacy.
 
+--smtp-encryption::
+	Specify the encryption to use, either 'ssl' or 'tls'.  Any other
+	value reverts to plain SMTP.  Default is the value of
+	'sendemail.smtpencryption'.
+
 --smtp-ssl::
-	If set, connects to the SMTP server using SSL.
-	Default is the value of the 'sendemail.smtpssl' configuration value;
-	if that is unspecified, does not use SSL.
+	Legacy alias for '--smtp-encryption=ssl'.
 
 --subject::
 	Specify the initial subject of the email thread.
@@ -229,8 +232,13 @@ sendemail.smtpuser::
 sendemail.smtppass::
 	Default SMTP-AUTH password.
 
+sendemail.smtpencryption::
+	Default encryption method.  Use 'ssl' for SSL (and specify an
+	appropriate port), or 'tls' for TLS.  Takes precedence over
+	'smtpssl' if both are specified.
+
 sendemail.smtpssl::
-	Boolean value specifying the default to the '--smtp-ssl' parameter.
+	Legacy boolean that sets 'smtpencryption=ssl' if enabled.
 
 Author
 ------
diff --git a/git-send-pack.html b/git-send-pack.html
index 4de169703..6fda2e417 100644
--- a/git-send-pack.html
+++ b/git-send-pack.html
@@ -272,13 +272,13 @@ git-send-pack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-send-pack</em> [--all] [--dry-run] [--force] [--receive-pack=&lt;git-receive-pack&gt;] [--verbose] [--thin] [&lt;host&gt;:]&lt;directory&gt; [&lt;ref&gt;&#8230;]</p>
+<p><em>git send-pack</em> [--all] [--dry-run] [--force] [--receive-pack=&lt;git-receive-pack&gt;] [--verbose] [--thin] [&lt;host&gt;:]&lt;directory&gt; [&lt;ref&gt;&#8230;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Usually you would want to use <a href="git-push.html">git-push(1)</a> which is a
-higher level wrapper of this command instead.</p>
-<p>Invokes <em>git-receive-pack</em> on a possibly remote repository, and
+<p>Usually you would want to use <tt>git-push</tt>, which is a
+higher-level wrapper of this command, instead. See <a href="git-push.html">git-push(1)</a>.</p>
+<p>Invokes <tt>git-receive-pack</tt> on a possibly remote repository, and
 updates it from the current repository, sending named refs.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -289,7 +289,7 @@ updates it from the current repository, sending named refs.</p>
 </dt>
 <dd>
 <p>
-        Path to the <em>git-receive-pack</em> program on the remote
+        Path to the <tt>git-receive-pack</tt> program on the remote
         end.  Sometimes useful when pushing to a remote
         repository over ssh, and you do not have the program in
         a directory on the default $PATH.
@@ -355,7 +355,7 @@ updates it from the current repository, sending named refs.</p>
 <dd>
 <p>
         A remote host to house the repository.  When this
-        part is specified, <em>git-receive-pack</em> is invoked via
+        part is specified, <tt>git-receive-pack</tt> is invoked via
         ssh.
 </p>
 </dd>
@@ -395,8 +395,8 @@ and the destination side (after the colon).  The ref to be
 pushed is determined by finding a match that matches the source
 side, and where it is pushed is determined by using the
 destination side. The rules used to match a ref are the same
-rules used by <a href="git-rev-parse.html">git-rev-parse(1)</a> to resolve a symbolic ref
-name.</p>
+rules used by <tt>git-rev-parse</tt> to resolve a symbolic ref
+name. See <a href="git-rev-parse.html">git-rev-parse(1)</a>.</p>
 <ul>
 <li>
 <p>
@@ -453,7 +453,7 @@ to disable the fast-forward check only on that ref.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:01 UTC
+Last updated 02-Jul-2008 03:02:02 UTC
 </div>
 </div>
 </body>
diff --git a/git-send-pack.txt b/git-send-pack.txt
index ba2fdaec0..410504df4 100644
--- a/git-send-pack.txt
+++ b/git-send-pack.txt
@@ -8,21 +8,21 @@ git-send-pack - Push objects over git protocol to another repository
 
 SYNOPSIS
 --------
-'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
 
 DESCRIPTION
 -----------
-Usually you would want to use linkgit:git-push[1] which is a
-higher level wrapper of this command instead.
+Usually you would want to use `git-push`, which is a
+higher-level wrapper of this command, instead. See linkgit:git-push[1].
 
-Invokes 'git-receive-pack' on a possibly remote repository, and
+Invokes `git-receive-pack` on a possibly remote repository, and
 updates it from the current repository, sending named refs.
 
 
 OPTIONS
 -------
 --receive-pack=<git-receive-pack>::
-	Path to the 'git-receive-pack' program on the remote
+	Path to the `git-receive-pack` program on the remote
 	end.  Sometimes useful when pushing to a remote
 	repository over ssh, and you do not have the program in
 	a directory on the default $PATH.
@@ -53,7 +53,7 @@ OPTIONS
 
 <host>::
 	A remote host to house the repository.  When this
-	part is specified, 'git-receive-pack' is invoked via
+	part is specified, `git-receive-pack` is invoked via
 	ssh.
 
 <directory>::
@@ -86,8 +86,8 @@ and the destination side (after the colon).  The ref to be
 pushed is determined by finding a match that matches the source
 side, and where it is pushed is determined by using the
 destination side. The rules used to match a ref are the same
-rules used by linkgit:git-rev-parse[1] to resolve a symbolic ref
-name.
+rules used by `git-rev-parse` to resolve a symbolic ref
+name. See linkgit:git-rev-parse[1].
 
  - It is an error if <src> does not match exactly one of the
    local refs.
diff --git a/git-sh-setup.html b/git-sh-setup.html
index ef0f26e88..797b60230 100644
--- a/git-sh-setup.html
+++ b/git-sh-setup.html
@@ -383,7 +383,7 @@ get_author_ident_from_commit
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 30-Jun-2008 09:04:39 UTC
+Last updated 02-Jul-2008 03:02:03 UTC
 </div>
 </div>
 </body>
diff --git a/git-shell.html b/git-shell.html
index 635b0918c..66706ccae 100644
--- a/git-shell.html
+++ b/git-shell.html
@@ -272,7 +272,7 @@ git-shell(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-shell</em> -c &lt;command&gt; &lt;argument&gt;</p>
+<p><em>$(git --exec-path)/git-shell</em> -c &lt;command&gt; &lt;argument&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -298,7 +298,7 @@ are permitted to be called, with a single required argument.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:11 UTC
+Last updated 02-Jul-2008 03:02:02 UTC
 </div>
 </div>
 </body>
diff --git a/git-shell.txt b/git-shell.txt
index bd09196ac..9b2ae7f26 100644
--- a/git-shell.txt
+++ b/git-shell.txt
@@ -8,7 +8,7 @@ git-shell - Restricted login shell for GIT-only SSH access
 
 SYNOPSIS
 --------
-'git-shell' -c <command> <argument>
+'$(git --exec-path)/git-shell' -c <command> <argument>
 
 DESCRIPTION
 -----------
diff --git a/git-shortlog.html b/git-shortlog.html
index 80b7a62e3..4f86959aa 100644
--- a/git-shortlog.html
+++ b/git-shortlog.html
@@ -273,12 +273,12 @@ git-shortlog(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content">git-log --pretty=short | <em>git-shortlog</em> [-h] [-n] [-s] [-e] [-w]
-git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[&lt;width&gt;[,&lt;indent1&gt;[,&lt;indent2&gt;]]]] [&lt;committish&gt;&#8230;]</div></div>
+<div class="content">git log --pretty=short | <em>git shortlog</em> [-h] [-n] [-s] [-e] [-w]
+git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[&lt;width&gt;[,&lt;indent1&gt;[,&lt;indent2&gt;]]]] [&lt;committish&gt;&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Summarizes <em>git log</em> output in a format suitable for inclusion
+<p>Summarizes <tt>git-log</tt> output in a format suitable for inclusion
 in release announcements. Each commit will be grouped by author and
 the first line of the commit message will be shown.</p>
 <p>Additionally, "[PATCH]" will be stripped from the commit description.</p>
@@ -371,7 +371,7 @@ Eve Jones &lt;eve@laptop.(none)&gt;</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:01 UTC
+Last updated 02-Jul-2008 03:02:02 UTC
 </div>
 </div>
 </body>
diff --git a/git-shortlog.txt b/git-shortlog.txt
index daa64d4d8..6e4cbc4fd 100644
--- a/git-shortlog.txt
+++ b/git-shortlog.txt
@@ -8,12 +8,12 @@ git-shortlog - Summarize 'git log' output
 SYNOPSIS
 --------
 [verse]
-git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e] [-w]
-git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
+git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
+git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
 
 DESCRIPTION
 -----------
-Summarizes 'git log' output in a format suitable for inclusion
+Summarizes `git-log` output in a format suitable for inclusion
 in release announcements. Each commit will be grouped by author and
 the first line of the commit message will be shown.
 
diff --git a/git-show-branch.html b/git-show-branch.html
index df757cf02..596ea4012 100644
--- a/git-show-branch.html
+++ b/git-show-branch.html
@@ -273,10 +273,10 @@ git-show-branch(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-show-branch</em> [--all] [--remotes] [--topo-order] [--current]
+<div class="content"><em>git show-branch</em> [--all] [--remotes] [--topo-order] [--current]
                 [--more=&lt;n&gt; | --list | --independent | --merge-base]
                 [--no-name | --sha1-name] [--topics] [&lt;rev&gt; | &lt;glob&gt;]&#8230;
-<em>git-show-branch</em> (-g|--reflog)[=&lt;n&gt;[,&lt;base&gt;]] [--list] [&lt;ref&gt;]</div></div>
+<em>git show-branch</em> (-g|--reflog)[=&lt;n&gt;[,&lt;base&gt;]] [--list] [&lt;ref&gt;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -295,7 +295,7 @@ no &lt;rev&gt; nor &lt;glob&gt; is given on the command line.</p>
 </dt>
 <dd>
 <p>
-        Arbitrary extended SHA1 expression (see <tt>git-rev-parse</tt>)
+        Arbitrary extended SHA1 expression (see <a href="git-rev-parse.html">git-rev-parse(1)</a>)
         that typically names a branch HEAD or a tag.
 </p>
 </dd>
@@ -390,7 +390,7 @@ no &lt;rev&gt; nor &lt;glob&gt; is given on the command line.</p>
 <dd>
 <p>
         Instead of showing the commit list, just act like the
-        <em>git-merge-base -a</em> command, except that it can accept
+        <tt>git-merge-base -a</tt> command, except that it can accept
         more than two heads.
 </p>
 </dd>
@@ -527,7 +527,7 @@ topologically related with each other.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:01 UTC
+Last updated 02-Jul-2008 03:02:02 UTC
 </div>
 </div>
 </body>
diff --git a/git-show-branch.txt b/git-show-branch.txt
index de9e8f885..578bdb785 100644
--- a/git-show-branch.txt
+++ b/git-show-branch.txt
@@ -8,10 +8,10 @@ git-show-branch - Show branches and their commits
 SYNOPSIS
 --------
 [verse]
-'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
+'git show-branch' [--all] [--remotes] [--topo-order] [--current]
 		[--more=<n> | --list | --independent | --merge-base]
 		[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
-'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
+'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
 
 DESCRIPTION
 -----------
@@ -29,7 +29,7 @@ no <rev> nor <glob> is given on the command line.
 OPTIONS
 -------
 <rev>::
-	Arbitrary extended SHA1 expression (see `git-rev-parse`)
+	Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
 	that typically names a branch HEAD or a tag.
 
 <glob>::
@@ -75,7 +75,7 @@ OPTIONS
 
 --merge-base::
 	Instead of showing the commit list, just act like the
-	'git-merge-base -a' command, except that it can accept
+	`git-merge-base -a` command, except that it can accept
 	more than two heads.
 
 --independent::
diff --git a/git-show-index.html b/git-show-index.html
index 038bf8648..29ff1070d 100644
--- a/git-show-index.html
+++ b/git-show-index.html
@@ -272,14 +272,14 @@ git-show-index(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-show-index</em> &lt; idx-file</p>
+<p><em>git show-index</em> &lt; idx-file</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Reads given idx file for packed git archive created with
-git-pack-objects command, and dumps its contents.</p>
+<tt>git-pack-objects</tt> command, and dumps its contents.</p>
 <p>The information it outputs is subset of what you can get from
-<em>git-verify-pack -v</em>; this command only shows the packfile
+<tt>git-verify-pack -v</tt>; this command only shows the packfile
 offset and SHA1 of each object.</p>
 </div>
 <h2>Author</h2>
@@ -296,7 +296,7 @@ offset and SHA1 of each object.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:13 UTC
+Last updated 02-Jul-2008 03:02:02 UTC
 </div>
 </div>
 </body>
diff --git a/git-show-index.txt b/git-show-index.txt
index 891f0eff2..4ae6ede11 100644
--- a/git-show-index.txt
+++ b/git-show-index.txt
@@ -8,16 +8,16 @@ git-show-index - Show packed archive index
 
 SYNOPSIS
 --------
-'git-show-index' < idx-file
+'git show-index' < idx-file
 
 
 DESCRIPTION
 -----------
 Reads given idx file for packed git archive created with
-git-pack-objects command, and dumps its contents.
+`git-pack-objects` command, and dumps its contents.
 
 The information it outputs is subset of what you can get from
-'git-verify-pack -v'; this command only shows the packfile
+`git-verify-pack -v`; this command only shows the packfile
 offset and SHA1 of each object.
 
 
diff --git a/git-show-ref.html b/git-show-ref.html
index 5c3f663c4..dffd3eded 100644
--- a/git-show-ref.html
+++ b/git-show-ref.html
@@ -273,9 +273,9 @@ git-show-ref(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-show-ref</em> [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+<div class="content"><em>git show-ref</em> [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
              [-s|--hash] [--abbrev] [--tags] [--heads] [--] &lt;pattern&gt;&#8230;
-<em>git-show-ref</em> --exclude-existing[=pattern]</div></div>
+<em>git show-ref</em> --exclude-existing[=pattern]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -381,7 +381,7 @@ in the <tt>.git</tt> directory.</p>
 </dt>
 <dd>
 <p>
-        Make git-show-ref act as a filter that reads refs from stdin of the
+        Make <tt>git-show-ref</tt> act as a filter that reads refs from stdin of the
         form "<sup>(?:&lt;anything&gt;\s)?&lt;refname&gt;(?:\</sup>{})?$" and performs the
         following actions on each:
         (1) strip "^{}" at the end of line if any;
@@ -443,13 +443,13 @@ if such references exists.</p>
 <pre><tt>        git show-ref --verify refs/heads/master</tt></pre>
 </div></div>
 <p>will only match the exact branch called "master".</p>
-<p>If nothing matches, <a href="git-show-ref.html">git-show-ref(1)</a> will return an error code of 1,
+<p>If nothing matches, <tt>git-show-ref</tt> will return an error code of 1,
 and in the case of verification, it will show an error message.</p>
 <p>For scripting, you can ask it to be quiet with the "--quiet" flag, which
 allows you to do things like</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>        git-show-ref --quiet --verify -- "refs/heads/$headname" ||
+<pre><tt>        git show-ref --quiet --verify -- "refs/heads/$headname" ||
                 echo "$headname is not a valid branch"</tt></pre>
 </div></div>
 <p>to check whether a particular branch exists or not (notice how we don't
@@ -481,7 +481,7 @@ Man page by Jonas Fonseca &lt;fonseca@diku.dk&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:01 UTC
+Last updated 02-Jul-2008 03:02:03 UTC
 </div>
 </div>
 </body>
diff --git a/git-show-ref.txt b/git-show-ref.txt
index 6b99529b6..a78a7dcf7 100644
--- a/git-show-ref.txt
+++ b/git-show-ref.txt
@@ -8,9 +8,9 @@ git-show-ref - List references in a local repository
 SYNOPSIS
 --------
 [verse]
-'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
 	     [-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
-'git-show-ref' --exclude-existing[=pattern]
+'git show-ref' --exclude-existing[=pattern]
 
 DESCRIPTION
 -----------
@@ -74,7 +74,7 @@ OPTIONS
 --exclude-existing::
 --exclude-existing=pattern::
 
-	Make git-show-ref act as a filter that reads refs from stdin of the
+	Make `git-show-ref` act as a filter that reads refs from stdin of the
 	form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the
 	following actions on each:
 	(1) strip "^{}" at the end of line if any;
@@ -137,14 +137,14 @@ When using the '--verify' flag, the command requires an exact path:
 
 will only match the exact branch called "master".
 
-If nothing matches, linkgit:git-show-ref[1] will return an error code of 1,
+If nothing matches, `git-show-ref` will return an error code of 1,
 and in the case of verification, it will show an error message.
 
 For scripting, you can ask it to be quiet with the "--quiet" flag, which
 allows you to do things like
 
 -----------------------------------------------------------------------------
-	git-show-ref --quiet --verify -- "refs/heads/$headname" ||
+	git show-ref --quiet --verify -- "refs/heads/$headname" ||
 		echo "$headname is not a valid branch"
 -----------------------------------------------------------------------------
 
diff --git a/git-show.html b/git-show.html
index d6c44a5ed..6f69343c4 100644
--- a/git-show.html
+++ b/git-show.html
@@ -272,19 +272,19 @@ git-show(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-show</em> [options] &lt;object&gt;&#8230;</p>
+<p><em>git show</em> [options] &lt;object&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Shows one or more objects (blobs, trees, tags and commits).</p>
 <p>For commits it shows the log message and textual diff. It also
 presents the merge commit in a special format as produced by
-<em>git-diff-tree --cc</em>.</p>
+<tt>git-diff-tree --cc</tt>.</p>
 <p>For tags, it shows the tag message and the referenced objects.</p>
-<p>For trees, it shows the names (equivalent to <a href="git-ls-tree.html">git-ls-tree(1)</a>
+<p>For trees, it shows the names (equivalent to <tt>git-ls-tree</tt>
 with --name-only).</p>
 <p>For plain blobs, it shows the plain contents.</p>
-<p>The command takes options applicable to the <a href="git-diff-tree.html">git-diff-tree(1)</a> command to
+<p>The command takes options applicable to the <tt>git-diff-tree</tt> command to
 control how the changes the commit introduces are shown.</p>
 <p>This manual page describes only the most frequently used options.</p>
 </div>
@@ -792,7 +792,7 @@ Johannes Schindelin &lt;Johannes.Schindelin@gmx.de&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:43 UTC
+Last updated 02-Jul-2008 03:02:03 UTC
 </div>
 </div>
 </body>
diff --git a/git-show.txt b/git-show.txt
index baaf2bc8f..70b54aec2 100644
--- a/git-show.txt
+++ b/git-show.txt
@@ -8,7 +8,7 @@ git-show - Show various types of objects
 
 SYNOPSIS
 --------
-'git-show' [options] <object>...
+'git show' [options] <object>...
 
 DESCRIPTION
 -----------
@@ -16,16 +16,16 @@ Shows one or more objects (blobs, trees, tags and commits).
 
 For commits it shows the log message and textual diff. It also
 presents the merge commit in a special format as produced by
-'git-diff-tree --cc'.
+`git-diff-tree --cc`.
 
 For tags, it shows the tag message and the referenced objects.
 
-For trees, it shows the names (equivalent to linkgit:git-ls-tree[1]
+For trees, it shows the names (equivalent to `git-ls-tree`
 with \--name-only).
 
 For plain blobs, it shows the plain contents.
 
-The command takes options applicable to the linkgit:git-diff-tree[1] command to
+The command takes options applicable to the `git-diff-tree` command to
 control how the changes the commit introduces are shown.
 
 This manual page describes only the most frequently used options.
diff --git a/git-stash.html b/git-stash.html
index 2a372db68..ccc71e40b 100644
--- a/git-stash.html
+++ b/git-stash.html
@@ -273,20 +273,20 @@ git-stash(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-stash</em> (list | show [&lt;stash&gt;] | apply [&lt;stash&gt;] | clear | drop [&lt;stash&gt;] | pop [&lt;stash&gt;])
-<em>git-stash</em> [save [&lt;message&gt;]]</div></div>
+<div class="content"><em>git stash</em> (list | show [&lt;stash&gt;] | apply [&lt;stash&gt;] | clear | drop [&lt;stash&gt;] | pop [&lt;stash&gt;])
+<em>git stash</em> [save [&lt;message&gt;]]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Use <em>git-stash</em> when you want to record the current state of the
+<p>Use <em>git stash</em> when you want to record the current state of the
 working directory and the index, but want to go back to a clean
 working directory.  The command saves your local modifications away
 and reverts the working directory to match the <tt>HEAD</tt> commit.</p>
 <p>The modifications stashed away by this command can be listed with
-<tt>git-stash list</tt>, inspected with <tt>git-stash show</tt>, and restored
-(potentially on top of a different commit) with <tt>git-stash apply</tt>.
-Calling git-stash without any arguments is equivalent to <tt>git-stash
-save</tt>.  A stash is by default listed as "WIP on <em>branchname</em> &#8230;", but
+<tt>git stash list</tt>, inspected with <tt>git stash show</tt>, and restored
+(potentially on top of a different commit) with <tt>git stash apply</tt>.
+Calling <tt>git stash</tt> without any arguments is equivalent to <tt>git stash save</tt>.
+A stash is by default listed as "WIP on <em>branchname</em> &#8230;", but
 you can give a more descriptive message on the command line when
 you create one.</p>
 <p>The latest stash you created is stored in <tt>$GIT_DIR/refs/stash</tt>; older
@@ -303,7 +303,7 @@ save [&lt;message&gt;]
 </dt>
 <dd>
 <p>
-        Save your local modifications to a new <em>stash</em>, and run <tt>git-reset
+        Save your local modifications to a new <em>stash</em>, and run <tt>git reset
         --hard</tt> to revert them.  This is the default action when no
         subcommand is given. The &lt;message&gt; part is optional and gives
         the description along with the stashed state.
@@ -325,8 +325,8 @@ list [&lt;options&gt;]
 <pre><tt>stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
 stash@{1}: On master: 9cc0589... Add git-stash</tt></pre>
 </div></div>
-<p>The command takes options applicable to the <a href="git-log.html">git-log(1)</a>
-command to control what is shown and how.</p>
+<p>The command takes options applicable to the <tt>git-log</tt>
+command to control what is shown and how. See <a href="git-log.html">git-log(1)</a>.</p>
 </dd>
 <dt>
 show [&lt;stash&gt;]
@@ -336,7 +336,7 @@ show [&lt;stash&gt;]
         Show the changes recorded in the stash as a diff between the
         stashed state and its original parent. When no <tt>&lt;stash&gt;</tt> is given,
         shows the latest one. By default, the command shows the diffstat, but
-        it will accept any format known to <tt>git-diff</tt> (e.g., <tt>git-stash show
+        it will accept any format known to <tt>git-diff</tt> (e.g., <tt>git stash show
         -p stash@{1}</tt> to view the second most recent stash in patch form).
 </p>
 </dd>
@@ -482,7 +482,7 @@ $ git stash apply
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:16 UTC
+Last updated 02-Jul-2008 03:02:03 UTC
 </div>
 </div>
 </body>
diff --git a/git-stash.txt b/git-stash.txt
index baa4f55b4..23ac33129 100644
--- a/git-stash.txt
+++ b/git-stash.txt
@@ -8,22 +8,22 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
-'git-stash' [save [<message>]]
+'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' [save [<message>]]
 
 DESCRIPTION
 -----------
 
-Use 'git-stash' when you want to record the current state of the
+Use 'git stash' when you want to record the current state of the
 working directory and the index, but want to go back to a clean
 working directory.  The command saves your local modifications away
 and reverts the working directory to match the `HEAD` commit.
 
 The modifications stashed away by this command can be listed with
-`git-stash list`, inspected with `git-stash show`, and restored
-(potentially on top of a different commit) with `git-stash apply`.
-Calling git-stash without any arguments is equivalent to `git-stash
-save`.  A stash is by default listed as "WIP on 'branchname' ...", but
+`git stash list`, inspected with `git stash show`, and restored
+(potentially on top of a different commit) with `git stash apply`.
+Calling `git stash` without any arguments is equivalent to `git stash save`.
+A stash is by default listed as "WIP on 'branchname' ...", but
 you can give a more descriptive message on the command line when
 you create one.
 
@@ -38,7 +38,7 @@ OPTIONS
 
 save [<message>]::
 
-	Save your local modifications to a new 'stash', and run `git-reset
+	Save your local modifications to a new 'stash', and run `git reset
 	--hard` to revert them.  This is the default action when no
 	subcommand is given. The <message> part is optional and gives
 	the description along with the stashed state.
@@ -56,15 +56,15 @@ stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
 stash@{1}: On master: 9cc0589... Add git-stash
 ----------------------------------------------------------------
 +
-The command takes options applicable to the linkgit:git-log[1]
-command to control what is shown and how.
+The command takes options applicable to the `git-log`
+command to control what is shown and how. See linkgit:git-log[1].
 
 show [<stash>]::
 
 	Show the changes recorded in the stash as a diff between the
 	stashed state and its original parent. When no `<stash>` is given,
 	shows the latest one. By default, the command shows the diffstat, but
-	it will accept any format known to `git-diff` (e.g., `git-stash show
+	it will accept any format known to `git-diff` (e.g., `git stash show
 	-p stash@\{1}` to view the second most recent stash in patch form).
 
 apply [--index] [<stash>]::
diff --git a/git-status.html b/git-status.html
index 172fd7f1b..35677f961 100644
--- a/git-status.html
+++ b/git-status.html
@@ -272,7 +272,7 @@ git-status(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-status</em> &lt;options&gt;&#8230;</p>
+<p><em>git status</em> &lt;options&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,14 +281,14 @@ current HEAD commit, paths that have differences between the working
 tree and the index file, and paths in the working tree that are not
 tracked by git (and are not ignored by <a href="gitignore.html">gitignore(5)</a>). The first
 are what you _would_ commit by running <tt>git commit</tt>; the second and
-third are what you _could_ commit by running <tt>git add</tt> before running
+third are what you _could_ commit by running <tt>git-add</tt> before running
 <tt>git commit</tt>.</p>
 <p>The command takes the same set of options as <tt>git-commit</tt>; it
 shows what would be committed if the same options are given to
 <tt>git-commit</tt>.</p>
 <p>If there is no path that is different between the index file and
 the current HEAD commit (i.e., there is nothing to commit by running
-<tt>git-commit</tt>), the command exits with non-zero status.</p>
+<tt>git commit</tt>), the command exits with non-zero status.</p>
 </div>
 <h2>OUTPUT</h2>
 <div class="sectionbody">
@@ -332,7 +332,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:16 UTC
+Last updated 02-Jul-2008 03:02:04 UTC
 </div>
 </div>
 </body>
diff --git a/git-status.txt b/git-status.txt
index fef62b16d..c9d4a046c 100644
--- a/git-status.txt
+++ b/git-status.txt
@@ -8,7 +8,7 @@ git-status - Show the working tree status
 
 SYNOPSIS
 --------
-'git-status' <options>...
+'git status' <options>...
 
 DESCRIPTION
 -----------
@@ -17,7 +17,7 @@ current HEAD commit, paths that have differences between the working
 tree and the index file, and paths in the working tree that are not
 tracked by git (and are not ignored by linkgit:gitignore[5]). The first
 are what you _would_ commit by running `git commit`; the second and
-third are what you _could_ commit by running `git add` before running
+third are what you _could_ commit by running `git-add` before running
 `git commit`.
 
 The command takes the same set of options as `git-commit`; it
@@ -26,7 +26,7 @@ shows what would be committed if the same options are given to
 
 If there is no path that is different between the index file and
 the current HEAD commit (i.e., there is nothing to commit by running
-`git-commit`), the command exits with non-zero status.
+`git commit`), the command exits with non-zero status.
 
 
 OUTPUT
diff --git a/git-stripspace.html b/git-stripspace.html
index fe10615b7..6ce84ea6a 100644
--- a/git-stripspace.html
+++ b/git-stripspace.html
@@ -272,7 +272,7 @@ git-stripspace(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-stripspace</em> [-s | --strip-comments] &lt; &lt;stream&gt;</p>
+<p><em>git stripspace</em> [-s | --strip-comments] &lt; &lt;stream&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -316,7 +316,7 @@ git-stripspace(1) Manual Page
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:02 UTC
+Last updated 02-Jul-2008 03:02:04 UTC
 </div>
 </div>
 </body>
diff --git a/git-stripspace.txt b/git-stripspace.txt
index 8421a39f2..7508c0e42 100644
--- a/git-stripspace.txt
+++ b/git-stripspace.txt
@@ -8,7 +8,7 @@ git-stripspace - Filter out empty lines
 
 SYNOPSIS
 --------
-'git-stripspace' [-s | --strip-comments] < <stream>
+'git stripspace' [-s | --strip-comments] < <stream>
 
 DESCRIPTION
 -----------
diff --git a/git-submodule.html b/git-submodule.html
index 5dcaf8534..8c5a62153 100644
--- a/git-submodule.html
+++ b/git-submodule.html
@@ -273,11 +273,11 @@ git-submodule(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-submodule</em> [--quiet] add [-b branch] [--] &lt;repository&gt; [&lt;path&gt;]
-<em>git-submodule</em> [--quiet] status [--cached] [--] [&lt;path&gt;&#8230;]
-<em>git-submodule</em> [--quiet] init [--] [&lt;path&gt;&#8230;]
-<em>git-submodule</em> [--quiet] update [--init] [--] [&lt;path&gt;&#8230;]
-<em>git-submodule</em> [--quiet] summary [--summary-limit &lt;n&gt;] [commit] [--] [&lt;path&gt;&#8230;]</div></div>
+<div class="content"><em>git submodule</em> [--quiet] add [-b branch] [--] &lt;repository&gt; [&lt;path&gt;]
+<em>git submodule</em> [--quiet] status [--cached] [--] [&lt;path&gt;&#8230;]
+<em>git submodule</em> [--quiet] init [--] [&lt;path&gt;&#8230;]
+<em>git submodule</em> [--quiet] update [--init] [--] [&lt;path&gt;&#8230;]
+<em>git submodule</em> [--quiet] summary [--summary-limit &lt;n&gt;] [commit] [--] [&lt;path&gt;&#8230;]</div></div>
 </div>
 <h2>COMMANDS</h2>
 <div class="sectionbody">
@@ -305,11 +305,11 @@ status
 <p>
         Show the status of the submodules. This will print the SHA-1 of the
         currently checked out commit for each submodule, along with the
-        submodule path and the output of <a href="git-describe.html">git-describe(1)</a> for the
+        submodule path and the output of <tt>git-describe</tt> for the
         SHA-1. Each SHA-1 will be prefixed with <tt>-</tt> if the submodule is not
         initialized and <tt>+</tt> if the currently checked out submodule commit
         does not match the SHA-1 found in the index of the containing
-        repository. This command is the default command for git-submodule.
+        repository. This command is the default command for <tt>git-submodule</tt>.
 </p>
 </dd>
 <dt>
@@ -428,7 +428,7 @@ for details.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:02 UTC
+Last updated 02-Jul-2008 03:02:04 UTC
 </div>
 </div>
 </body>
diff --git a/git-submodule.txt b/git-submodule.txt
index 441ae1483..9c4052c58 100644
--- a/git-submodule.txt
+++ b/git-submodule.txt
@@ -9,11 +9,11 @@ git-submodule - Initialize, update or inspect submodules
 SYNOPSIS
 --------
 [verse]
-'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
-'git-submodule' [--quiet] status [--cached] [--] [<path>...]
-'git-submodule' [--quiet] init [--] [<path>...]
-'git-submodule' [--quiet] update [--init] [--] [<path>...]
-'git-submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
+'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
+'git submodule' [--quiet] status [--cached] [--] [<path>...]
+'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] update [--init] [--] [<path>...]
+'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
 
 
 COMMANDS
@@ -32,11 +32,11 @@ add::
 status::
 	Show the status of the submodules. This will print the SHA-1 of the
 	currently checked out commit for each submodule, along with the
-	submodule path and the output of linkgit:git-describe[1] for the
+	submodule path and the output of `git-describe` for the
 	SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
 	initialized and `+` if the currently checked out submodule commit
 	does not match the SHA-1 found in the index of the containing
-	repository. This command is the default command for git-submodule.
+	repository. This command is the default command for `git-submodule`.
 
 init::
 	Initialize the submodules, i.e. register in .git/config each submodule
diff --git a/git-svn.html b/git-svn.html
index 545240f7a..6c56d7df1 100644
--- a/git-svn.html
+++ b/git-svn.html
@@ -272,19 +272,19 @@ git-svn(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-svn</em> &lt;command&gt; [options] [arguments]</p>
+<p><em>git svn</em> &lt;command&gt; [options] [arguments]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>git-svn is a simple conduit for changesets between Subversion and git.
+<p><tt>git-svn</tt> is a simple conduit for changesets between Subversion and git.
 It is not to be confused with <a href="git-svnimport.html">git-svnimport(1)</a>, which is
 read-only.</p>
-<p>git-svn was originally designed for an individual developer who wants a
+<p><tt>git-svn</tt> was originally designed for an individual developer who wants a
 bidirectional flow of changesets between a single branch in Subversion
 and an arbitrary number of branches in git.  Since its inception,
-git-svn has gained the ability to track multiple branches in a manner
-similar to git-svnimport.</p>
-<p>git-svn is especially useful when it comes to tracking repositories
+<tt>git-svn</tt> has gained the ability to track multiple branches in a manner
+similar to <tt>git-svnimport</tt>.</p>
+<p><tt>git-svn</tt> is especially useful when it comes to tracking repositories
 not organized in the way Subversion developers recommend (trunk,
 branches, tags directories).</p>
 </div>
@@ -297,7 +297,7 @@ branches, tags directories).</p>
 <dd>
 <p>
         Initializes an empty git repository with additional
-        metadata directories for git-svn.  The Subversion URL
+        metadata directories for <tt>git-svn</tt>.  The Subversion URL
         may be specified as a command-line argument, or as full
         URL arguments to -T/-t/-b.  Optionally, the target
         directory to operate on can be specified as a second
@@ -457,13 +457,13 @@ branches, tags directories).</p>
         This fetches revisions from the SVN parent of the current HEAD
         and rebases the current (uncommitted to SVN) work against it.
 </p>
-<p>This works similarly to <em>svn update</em> or <em>git-pull</em> except that
-it preserves linear history with <em>git-rebase</em> instead of
-<em>git-merge</em> for ease of dcommiting with git-svn.</p>
-<p>This accepts all options that <em>git-svn fetch</em> and <em>git-rebase</em>
-accepts.  However <em>--fetch-all</em> only fetches from the current
+<p>This works similarly to <tt>svn update</tt> or <tt>git-pull</tt> except that
+it preserves linear history with <tt>git-rebase</tt> instead of
+<tt>git-merge</tt> for ease of dcommiting with <tt>git-svn</tt>.</p>
+<p>This accepts all options that <tt>git-svn fetch</tt> and <tt>git-rebase</tt>
+accept.  However, <em>--fetch-all</em> only fetches from the current
 [svn-remote], and not all [svn-remote] definitions.</p>
-<p>Like <em>git-rebase</em>; this requires that the working tree be clean
+<p>Like <tt>git-rebase</tt>; this requires that the working tree be clean
 and have no uncommitted changes.</p>
 <dl>
 <dt>
@@ -474,7 +474,7 @@ and have no uncommitted changes.</p>
 </dt>
 <dd>
 <p>
-        Do not fetch remotely; only run <em>git-rebase</em> against the
+        Do not fetch remotely; only run <tt>git-rebase</tt> against the
         last fetched commit from the upstream SVN.
 </p>
 </dd>
@@ -489,7 +489,7 @@ and have no uncommitted changes.</p>
         repository, and then rebase or reset (depending on whether or
         not there is a diff between SVN and head).  This will create
         a revision in SVN for each commit in git.
-        It is recommended that you run git-svn fetch and rebase (not
+        It is recommended that you run <tt>git-svn</tt> fetch and rebase (not
         pull or merge) your commits against the latest changes in the
         SVN repository.
         An optional command-line argument may be specified as an
@@ -585,7 +585,7 @@ client converts the UTC time to the local time (or based on the TZ=
 environment). This command has the same behaviour.</td>
 </tr></table>
 </div>
-<p>Any other arguments are passed directly to `git log'</p>
+<p>Any other arguments are passed directly to <tt>git-log</tt></p>
 </dd>
 <dt>
 <em>blame</em>
@@ -594,10 +594,10 @@ environment). This command has the same behaviour.</td>
 <p>
        Show what revision and author last modified each line of a file. The
        output of this mode is format-compatible with the output of
-       `svn blame' by default. Like the SVN blame command,
+       <tt>svn blame' by default. Like the SVN blame command,
        local uncommitted changes in the working copy are ignored;
        the version of the file in the HEAD revision is annotated. Unknown
-       arguments are passed directly to git-blame.
+       arguments are passed directly to `git-blame</tt>.
 </p>
 <dl>
 <dt>
@@ -605,7 +605,7 @@ environment). This command has the same behaviour.</td>
 </dt>
 <dd>
 <p>
-        Produce output in the same format as `git blame', but with
+        Produce output in the same format as <tt>git-blame</tt>, but with
         SVN revision numbers instead of git commit hashes. In this mode,
         changes that haven't been committed to SVN (including local
         working-copy edits) are shown as revision 0.
@@ -637,7 +637,7 @@ environment). This command has the same behaviour.</td>
         absolutely no attempts to do patching when committing to SVN, it
         simply overwrites files with those specified in the tree or
         commit.  All merging is assumed to have taken place
-        independently of git-svn functions.
+        independently of <tt>git-svn</tt> functions.
 </p>
 </dd>
 <dt>
@@ -668,12 +668,12 @@ environment). This command has the same behaviour.</td>
 <p>
         Commits the diff of two tree-ish arguments from the
         command-line.  This command is intended for interoperability with
-        git-svnimport and does not rely on being inside an git-svn
-        init-ed repository.  This command takes three arguments, (a) the
+        <tt>git-svnimport</tt> and does not rely on being inside an <tt>git-svn
+        init</tt>-ed repository.  This command takes three arguments, (a) the
         original tree to diff against, (b) the new tree result, (c) the
         URL of the target Subversion repository.  The final argument
-        (URL) may be omitted if you are working from a git-svn-aware
-        repository (that has been init-ed with git-svn).
+        (URL) may be omitted if you are working from a <tt>git-svn</tt>-aware
+        repository (that has been <tt>init</tt>-ed with <tt>git-svn</tt>).
         The -r&lt;revision&gt; option is required for this.
 </p>
 </dd>
@@ -730,7 +730,7 @@ environment). This command has the same behaviour.</td>
 <dd>
 <p>
         Only used with the <em>init</em> command.
-        These are passed directly to <a href="git-init.html">git-init(1)</a>.
+        These are passed directly to <tt>git-init</tt>.
 </p>
 </dd>
 <dt>
@@ -762,7 +762,7 @@ Only used with the <em>set-tree</em> command.
 </p>
 <p>Read a list of commits from stdin and commit them in reverse
 order.  Only the leading sha1 is read from each line, so
-git-rev-list --pretty=oneline output can be used.</p>
+<tt>git-rev-list --pretty=oneline</tt> output can be used.</p>
 </dd>
 <dt>
 --rmdir
@@ -803,7 +803,7 @@ tree objects.</p>
 <p>
 Only used with the <em>dcommit</em>, <em>set-tree</em> and <em>commit-diff</em> commands.
 </p>
-<p>They are both passed directly to git-diff-tree see
+<p>They are both passed directly to <tt>git-diff-tree</tt>; see
 <a href="git-diff-tree.html">git-diff-tree(1)</a> for more information.</p>
 <div class="verseblock">
 <div class="content">config key: svn.l
@@ -817,17 +817,17 @@ config key: svn.findcopiesharder</div></div>
 </dt>
 <dd>
 <p>
-Syntax is compatible with the files used by git-svnimport and
-git-cvsimport:
+Syntax is compatible with the files used by <tt>git-svnimport</tt> and
+<tt>git-cvsimport</tt>:
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>        loginname = Joe User &lt;user@example.com&gt;</tt></pre>
 </div></div>
-<p>If this option is specified and git-svn encounters an SVN
-committer name that does not exist in the authors-file, git-svn
+<p>If this option is specified and <tt>git-svn</tt> encounters an SVN
+committer name that does not exist in the authors-file, <tt>git-svn</tt>
 will abort operation. The user will then have to add the
-appropriate entry.  Re-running the previous git-svn command
+appropriate entry.  Re-running the previous <tt>git-svn</tt> command
 after the authors-file is modified should continue operation.</p>
 <p>config key: svn.authorsfile</p>
 </dd>
@@ -839,7 +839,7 @@ after the authors-file is modified should continue operation.</p>
 </dt>
 <dd>
 <p>
-        Make git-svn less verbose.
+        Make <tt>git-svn</tt> less verbose.
 </p>
 </dd>
 <dt>
@@ -856,7 +856,7 @@ with many revisions.
 <p>--repack takes an optional argument for the number of revisions
 to fetch before repacking.  This defaults to repacking every
 1000 commits fetched if no argument is specified.</p>
-<p>--repack-flags are passed directly to <a href="git-repack.html">git-repack(1)</a>.</p>
+<p>--repack-flags are passed directly to <tt>git-repack</tt>.</p>
 <div class="verseblock">
 <div class="content">config key: svn.repack
 config key: svn.repackflags</div></div>
@@ -877,8 +877,8 @@ config key: svn.repackflags</div></div>
 <p>
 These are only used with the <em>dcommit</em> and <em>rebase</em> commands.
 </p>
-<p>Passed directly to git-rebase when using <em>dcommit</em> if a
-<em>git-reset</em> cannot be used (see dcommit).</p>
+<p>Passed directly to <tt>git-rebase</tt> when using <em>dcommit</em> if a
+<tt>git-reset</tt> cannot be used (see <em>dcommit</em>).</p>
 </dd>
 <dt>
 -n
@@ -954,12 +954,12 @@ svn-remote.&lt;name&gt;.noMetadata
 </dt>
 <dd>
 <p>
-This gets rid of the git-svn-id: lines at the end of every commit.
+This gets rid of the <em>git-svn-id:</em> lines at the end of every commit.
 </p>
-<p>If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+<p>If you lose your .git/svn/git-svn/.rev_db file, <tt>git-svn</tt> will not
 be able to rebuild it and you won't be able to fetch again,
 either.  This is fine for one-shot imports.</p>
-<p>The <em>git-svn log</em> command will not work on repositories using
+<p>The <tt>git-svn log</tt> command will not work on repositories using
 this, either.  Using this conflicts with the <em>useSvmProps</em>
 option for (hopefully) obvious reasons.</p>
 </dd>
@@ -971,7 +971,7 @@ svn-remote.&lt;name&gt;.useSvmProps
 </dt>
 <dd>
 <p>
-This allows git-svn to re-map repository URLs and UUIDs from
+This allows <tt>git-svn</tt> to re-map repository URLs and UUIDs from
 mirrors created using SVN::Mirror (or svk) for metadata.
 </p>
 <p>If an SVN revision has a property, "svm:headrev", it is likely
@@ -1001,7 +1001,7 @@ svn-remote.&lt;name&gt;.rewriteRoot
 <dd>
 <p>
         This allows users to create repositories from alternate
-        URLs.  For example, an administrator could run git-svn on the
+        URLs.  For example, an administrator could run <tt>git-svn</tt> on the
         server locally (accessing via file://) but wish to distribute
         the repository with a public http:// or svn:// URL in the
         metadata so users of it will see the public URL.
@@ -1009,7 +1009,7 @@ svn-remote.&lt;name&gt;.rewriteRoot
 </dd>
 </dl>
 <p>Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
-options all affect the metadata generated and used by git-svn; they
+options all affect the metadata generated and used by <tt>git-svn</tt>; they
 <strong>must</strong> be set in the configuration file before any history is imported
 and these settings should never be changed once they are set.</p>
 <p>Additionally, only one of these four options can be used per-svn-remote
@@ -1021,7 +1021,7 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt># Clone a repo (like git clone):
-        git-svn clone http://svn.foo.org/project/trunk
+        git svn clone http://svn.foo.org/project/trunk
 # Enter the newly cloned directory:
         cd trunk
 # You should be on master branch, double-check with git-branch
@@ -1030,19 +1030,19 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
         git commit ...
 # Something is committed to SVN, rebase your local changes against the
 # latest changes in SVN:
-        git-svn rebase
+        git svn rebase
 # Now commit your changes (that were committed previously using git) to SVN,
 # as well as automatically updating your working HEAD:
-        git-svn dcommit
+        git svn dcommit
 # Append svn:ignore settings to the default git exclude file:
-        git-svn show-ignore &gt;&gt; .git/info/exclude</tt></pre>
+        git svn show-ignore &gt;&gt; .git/info/exclude</tt></pre>
 </div></div>
 <p>Tracking and contributing to an entire Subversion-managed project
 (complete with a trunk, tags and branches):</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt># Clone a repo (like git clone):
-        git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+        git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
 # View all branches and tags you have cloned:
         git branch -r
 # Reset your master to trunk (or any other branch, replacing 'trunk'
@@ -1051,46 +1051,46 @@ section because they affect the <em>git-svn-id:</em> metadata line.</p>
 # You may only dcommit to one branch/tag/trunk at a time.  The usage
 # of dcommit/rebase/show-ignore should be the same as above.</tt></pre>
 </div></div>
-<p>The initial <em>git-svn clone</em> can be quite time-consuming
+<p>The initial <tt>git-svn clone</tt> can be quite time-consuming
 (especially for large Subversion repositories). If multiple
 people (or one person with multiple machines) want to use
-git-svn to interact with the same Subversion repository, you can
-do the initial <em>git-svn clone</em> to a repository on a server and
-have each person clone that repository with <em>git clone</em>:</p>
+<tt>git-svn</tt> to interact with the same Subversion repository, you can
+do the initial <tt>git-svn clone</tt> to a repository on a server and
+have each person clone that repository with <tt>git-clone</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt># Do the initial import on a server
-        ssh server "cd /pub &amp;&amp; git-svn clone http://svn.foo.org/project
+        ssh server "cd /pub &amp;&amp; git svn clone http://svn.foo.org/project
 # Clone locally - make sure the refs/remotes/ space matches the server
         mkdir project
         cd project
-        git-init
+        git init
         git remote add origin server:/pub/project
         git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
         git fetch
 # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
-        git-svn init http://svn.foo.org/project
+        git svn init http://svn.foo.org/project
 # Pull the latest changes from Subversion
-        git-svn rebase</tt></pre>
+        git svn rebase</tt></pre>
 </div></div>
 </div>
 <h2>REBASE VS. PULL/MERGE</h2>
 <div class="sectionbody">
-<p>Originally, git-svn recommended that the remotes/git-svn branch be
+<p>Originally, <tt>git-svn</tt> recommended that the <em>remotes/git-svn</em> branch be
 pulled or merged from.  This is because the author favored
-<em>git-svn set-tree B</em> to commit a single head rather than the
-<em>git-svn set-tree A..B</em> notation to commit multiple commits.</p>
-<p>If you use <em>git-svn set-tree A..B</em> to commit several diffs and you do
+<tt>git svn set-tree B</tt> to commit a single head rather than the
+<tt>git svn set-tree A..B</tt> notation to commit multiple commits.</p>
+<p>If you use <tt>git svn set-tree A..B</tt> to commit several diffs and you do
 not have the latest remotes/git-svn merged into my-branch, you should
-use <em>git-svn rebase</em> to update your work branch instead of <em>git pull</em> or
-<em>git merge</em>.  <em>pull/merge</em> can cause non-linear history to be flattened
+use <tt>git svn rebase</tt> to update your work branch instead of <tt>git pull</tt> or
+<tt>git merge</tt>.  <tt>pull</tt>/`merge' can cause non-linear history to be flattened
 when committing into SVN, which can lead to merge commits reversing
 previous commits in SVN.</p>
 </div>
 <h2>DESIGN PHILOSOPHY</h2>
 <div class="sectionbody">
 <p>Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result.  While git-svn can track
+with Subversion can be cumbersome as a result.  While <tt>git-svn</tt> can track
 copy history (including branches and tags) for repositories adopting a
 standard layout, it cannot yet represent merge history that happened
 inside git back upstream to SVN users.  Therefore it is advised that
@@ -1100,26 +1100,26 @@ compatibility with SVN (see the CAVEATS section below).</p>
 <h2>CAVEATS</h2>
 <div class="sectionbody">
 <p>For the sake of simplicity and interoperating with a less-capable system
-(SVN), it is recommended that all git-svn users clone, fetch and dcommit
-directly from the SVN server, and avoid all git-clone/pull/merge/push
+(SVN), it is recommended that all <tt>git-svn</tt> users clone, fetch and dcommit
+directly from the SVN server, and avoid all <tt>git-clone</tt>/<tt>pull</tt>/<tt>merge</tt>/<tt>push</tt>
 operations between git repositories and branches.  The recommended
 method of exchanging code between git branches and users is
-git-format-patch and git-am, or just dcommiting to the SVN repository.</p>
-<p>Running <em>git-merge</em> or <em>git-pull</em> is NOT recommended on a branch you
-plan to dcommit from.  Subversion does not represent merges in any
+<tt>git-format-patch</tt> and <tt>git-am</tt>, or just 'dcommit'ing to the SVN repository.</p>
+<p>Running <tt>git-merge</tt> or <tt>git-pull</tt> is NOT recommended on a branch you
+plan to <em>dcommit</em> from.  Subversion does not represent merges in any
 reasonable or useful fashion; so users using Subversion cannot see any
 merges you've made.  Furthermore, if you merge or pull from a git branch
-that is a mirror of an SVN branch, dcommit may commit to the wrong
+that is a mirror of an SVN branch, <em>dcommit</em> may commit to the wrong
 branch.</p>
-<p><em>git-clone</em> does not clone branches under the refs/remotes/ hierarchy or
-any git-svn metadata, or config.  So repositories created and managed with
-using git-svn should use rsync(1) for cloning, if cloning is to be done
+<p><tt>git-clone</tt> does not clone branches under the refs/remotes/ hierarchy or
+any <tt>git-svn</tt> metadata, or config.  So repositories created and managed with
+using <tt>git-svn</tt> should use <tt>rsync</tt> for cloning, if cloning is to be done
 at all.</p>
-<p>Since <em>dcommit</em> uses rebase internally, any git branches you git-push to
-before dcommit on will require forcing an overwrite of the existing ref
+<p>Since <em>dcommit</em> uses rebase internally, any git branches you <tt>git-push</tt> to
+before <em>dcommit</em> on will require forcing an overwrite of the existing ref
 on the remote repository.  This is generally considered bad practice,
-see the git-push(1) documentation for details.</p>
-<p>Do not use the --amend option of git-commit(1) on a change you've
+see the <a href="git-push.html">git-push(1)</a> documentation for details.</p>
+<p>Do not use the --amend option of <a href="git-commit.html">git-commit(1)</a> on a change you've
 already dcommitted.  It is considered bad practice to --amend commits
 you've already pushed to a remote repository for other users, and
 dcommit with SVN is analogous to that.</p>
@@ -1137,7 +1137,7 @@ for git to detect them.</p>
 </div>
 <h2>CONFIGURATION</h2>
 <div class="sectionbody">
-<p>git-svn stores [svn-remote] configuration information in the
+<p><tt>git-svn</tt> stores [svn-remote] configuration information in the
 repository .git/config file.  It is similar the core git
 [remote] sections except <em>fetch</em> keys do not accept glob
 arguments; but they are instead handled by the <em>branches</em>
@@ -1157,8 +1157,7 @@ listed below are allowed:</p>
 however the remote wildcard may be anywhere as long as it's own
 independent path component (surrounded by <em>/</em> or EOL).   This
 type of configuration is not automatically created by <em>init</em> and
-should be manually entered with a text-editor or using
-<a href="git-config.html">git-config(1)</a></p>
+should be manually entered with a text-editor or using <tt>git-config</tt>.</p>
 </div>
 <h2>SEE ALSO</h2>
 <div class="sectionbody">
@@ -1174,7 +1173,7 @@ should be manually entered with a text-editor or using
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 29-Jun-2008 08:48:21 UTC
+Last updated 02-Jul-2008 03:02:04 UTC
 </div>
 </div>
 </body>
diff --git a/git-svn.txt b/git-svn.txt
index c350ad0f8..6caa13061 100644
--- a/git-svn.txt
+++ b/git-svn.txt
@@ -7,21 +7,21 @@ git-svn - Bidirectional operation between a single Subversion branch and git
 
 SYNOPSIS
 --------
-'git-svn' <command> [options] [arguments]
+'git svn' <command> [options] [arguments]
 
 DESCRIPTION
 -----------
-git-svn is a simple conduit for changesets between Subversion and git.
+`git-svn` is a simple conduit for changesets between Subversion and git.
 It is not to be confused with linkgit:git-svnimport[1], which is
 read-only.
 
-git-svn was originally designed for an individual developer who wants a
+`git-svn` was originally designed for an individual developer who wants a
 bidirectional flow of changesets between a single branch in Subversion
 and an arbitrary number of branches in git.  Since its inception,
-git-svn has gained the ability to track multiple branches in a manner
-similar to git-svnimport.
+`git-svn` has gained the ability to track multiple branches in a manner
+similar to `git-svnimport`.
 
-git-svn is especially useful when it comes to tracking repositories
+`git-svn` is especially useful when it comes to tracking repositories
 not organized in the way Subversion developers recommend (trunk,
 branches, tags directories).
 
@@ -31,7 +31,7 @@ COMMANDS
 
 'init'::
 	Initializes an empty git repository with additional
-	metadata directories for git-svn.  The Subversion URL
+	metadata directories for `git-svn`.  The Subversion URL
 	may be specified as a command-line argument, or as full
 	URL arguments to -T/-t/-b.  Optionally, the target
 	directory to operate on can be specified as a second
@@ -107,20 +107,20 @@ COMMANDS
 	This fetches revisions from the SVN parent of the current HEAD
 	and rebases the current (uncommitted to SVN) work against it.
 
-This works similarly to 'svn update' or 'git-pull' except that
-it preserves linear history with 'git-rebase' instead of
-'git-merge' for ease of dcommiting with git-svn.
+This works similarly to `svn update` or `git-pull` except that
+it preserves linear history with `git-rebase` instead of
+`git-merge` for ease of dcommiting with `git-svn`.
 
-This accepts all options that 'git-svn fetch' and 'git-rebase'
-accepts.  However '--fetch-all' only fetches from the current
+This accepts all options that `git-svn fetch` and `git-rebase`
+accept.  However, '--fetch-all' only fetches from the current
 [svn-remote], and not all [svn-remote] definitions.
 
-Like 'git-rebase'; this requires that the working tree be clean
+Like `git-rebase`; this requires that the working tree be clean
 and have no uncommitted changes.
 
 -l;;
 --local;;
-	Do not fetch remotely; only run 'git-rebase' against the
+	Do not fetch remotely; only run `git-rebase` against the
 	last fetched commit from the upstream SVN.
 
 'dcommit'::
@@ -128,7 +128,7 @@ and have no uncommitted changes.
 	repository, and then rebase or reset (depending on whether or
 	not there is a diff between SVN and head).  This will create
 	a revision in SVN for each commit in git.
-	It is recommended that you run git-svn fetch and rebase (not
+	It is recommended that you run `git-svn` fetch and rebase (not
 	pull or merge) your commits against the latest changes in the
 	SVN repository.
 	An optional command-line argument may be specified as an
@@ -173,7 +173,7 @@ NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
 client converts the UTC time to the local time (or based on the TZ=
 environment). This command has the same behaviour.
 +
-Any other arguments are passed directly to `git log'
+Any other arguments are passed directly to `git-log`
 
 'blame'::
        Show what revision and author last modified each line of a file. The
@@ -181,10 +181,10 @@ Any other arguments are passed directly to `git log'
        `svn blame' by default. Like the SVN blame command,
        local uncommitted changes in the working copy are ignored;
        the version of the file in the HEAD revision is annotated. Unknown
-       arguments are passed directly to git-blame.
+       arguments are passed directly to `git-blame`.
 +
 --git-format;;
-	Produce output in the same format as `git blame', but with
+	Produce output in the same format as `git-blame`, but with
 	SVN revision numbers instead of git commit hashes. In this mode,
 	changes that haven't been committed to SVN (including local
 	working-copy edits) are shown as revision 0.
@@ -203,7 +203,7 @@ Any other arguments are passed directly to `git log'
 	absolutely no attempts to do patching when committing to SVN, it
 	simply overwrites files with those specified in the tree or
 	commit.  All merging is assumed to have taken place
-	independently of git-svn functions.
+	independently of `git-svn` functions.
 
 'create-ignore'::
 	Recursively finds the svn:ignore property on directories and
@@ -219,12 +219,12 @@ Any other arguments are passed directly to `git log'
 'commit-diff'::
 	Commits the diff of two tree-ish arguments from the
 	command-line.  This command is intended for interoperability with
-	git-svnimport and does not rely on being inside an git-svn
-	init-ed repository.  This command takes three arguments, (a) the
+	`git-svnimport` and does not rely on being inside an `git-svn
+	init`-ed repository.  This command takes three arguments, (a) the
 	original tree to diff against, (b) the new tree result, (c) the
 	URL of the target Subversion repository.  The final argument
-	(URL) may be omitted if you are working from a git-svn-aware
-	repository (that has been init-ed with git-svn).
+	(URL) may be omitted if you are working from a `git-svn`-aware
+	repository (that has been `init`-ed with `git-svn`).
 	The -r<revision> option is required for this.
 
 'info'::
@@ -255,7 +255,7 @@ OPTIONS
 --shared[={false|true|umask|group|all|world|everybody}]::
 --template=<template_directory>::
 	Only used with the 'init' command.
-	These are passed directly to linkgit:git-init[1].
+	These are passed directly to `git-init`.
 
 -r <ARG>::
 --revision <ARG>::
@@ -277,7 +277,7 @@ Only used with the 'set-tree' command.
 
 Read a list of commits from stdin and commit them in reverse
 order.  Only the leading sha1 is read from each line, so
-git-rev-list --pretty=oneline output can be used.
+`git-rev-list --pretty=oneline` output can be used.
 
 --rmdir::
 
@@ -307,7 +307,7 @@ config key: svn.edit
 
 Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
 
-They are both passed directly to git-diff-tree see
+They are both passed directly to `git-diff-tree`; see
 linkgit:git-diff-tree[1] for more information.
 
 [verse]
@@ -317,24 +317,24 @@ config key: svn.findcopiesharder
 -A<filename>::
 --authors-file=<filename>::
 
-Syntax is compatible with the files used by git-svnimport and
-git-cvsimport:
+Syntax is compatible with the files used by `git-svnimport` and
+`git-cvsimport`:
 
 ------------------------------------------------------------------------
 	loginname = Joe User <user@example.com>
 ------------------------------------------------------------------------
 
-If this option is specified and git-svn encounters an SVN
-committer name that does not exist in the authors-file, git-svn
+If this option is specified and `git-svn` encounters an SVN
+committer name that does not exist in the authors-file, `git-svn`
 will abort operation. The user will then have to add the
-appropriate entry.  Re-running the previous git-svn command
+appropriate entry.  Re-running the previous `git-svn` command
 after the authors-file is modified should continue operation.
 
 config key: svn.authorsfile
 
 -q::
 --quiet::
-	Make git-svn less verbose.
+	Make `git-svn` less verbose.
 
 --repack[=<n>]::
 --repack-flags=<flags>::
@@ -346,7 +346,7 @@ with many revisions.
 to fetch before repacking.  This defaults to repacking every
 1000 commits fetched if no argument is specified.
 
---repack-flags are passed directly to linkgit:git-repack[1].
+--repack-flags are passed directly to `git-repack`.
 
 [verse]
 config key: svn.repack
@@ -359,8 +359,8 @@ config key: svn.repackflags
 
 These are only used with the 'dcommit' and 'rebase' commands.
 
-Passed directly to git-rebase when using 'dcommit' if a
-'git-reset' cannot be used (see dcommit).
+Passed directly to `git-rebase` when using 'dcommit' if a
+`git-reset` cannot be used (see 'dcommit').
 
 -n::
 --dry-run::
@@ -411,20 +411,20 @@ CONFIG FILE-ONLY OPTIONS
 svn.noMetadata::
 svn-remote.<name>.noMetadata::
 
-This gets rid of the git-svn-id: lines at the end of every commit.
+This gets rid of the 'git-svn-id:' lines at the end of every commit.
 
-If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+If you lose your .git/svn/git-svn/.rev_db file, `git-svn` will not
 be able to rebuild it and you won't be able to fetch again,
 either.  This is fine for one-shot imports.
 
-The 'git-svn log' command will not work on repositories using
+The `git-svn log` command will not work on repositories using
 this, either.  Using this conflicts with the 'useSvmProps'
 option for (hopefully) obvious reasons.
 
 svn.useSvmProps::
 svn-remote.<name>.useSvmProps::
 
-This allows git-svn to re-map repository URLs and UUIDs from
+This allows `git-svn` to re-map repository URLs and UUIDs from
 mirrors created using SVN::Mirror (or svk) for metadata.
 
 If an SVN revision has a property, "svm:headrev", it is likely
@@ -443,7 +443,7 @@ svn-remote.<name>.useSvnsyncprops::
 
 svn-remote.<name>.rewriteRoot::
 	This allows users to create repositories from alternate
-	URLs.  For example, an administrator could run git-svn on the
+	URLs.  For example, an administrator could run `git-svn` on the
 	server locally (accessing via file://) but wish to distribute
 	the repository with a public http:// or svn:// URL in the
 	metadata so users of it will see the public URL.
@@ -451,7 +451,7 @@ svn-remote.<name>.rewriteRoot::
 --
 
 Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
-options all affect the metadata generated and used by git-svn; they
+options all affect the metadata generated and used by `git-svn`; they
 *must* be set in the configuration file before any history is imported
 and these settings should never be changed once they are set.
 
@@ -466,7 +466,7 @@ Tracking and contributing to the trunk of a Subversion-managed project:
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
-	git-svn clone http://svn.foo.org/project/trunk
+	git svn clone http://svn.foo.org/project/trunk
 # Enter the newly cloned directory:
 	cd trunk
 # You should be on master branch, double-check with git-branch
@@ -475,12 +475,12 @@ Tracking and contributing to the trunk of a Subversion-managed project:
 	git commit ...
 # Something is committed to SVN, rebase your local changes against the
 # latest changes in SVN:
-	git-svn rebase
+	git svn rebase
 # Now commit your changes (that were committed previously using git) to SVN,
 # as well as automatically updating your working HEAD:
-	git-svn dcommit
+	git svn dcommit
 # Append svn:ignore settings to the default git exclude file:
-	git-svn show-ignore >> .git/info/exclude
+	git svn show-ignore >> .git/info/exclude
 ------------------------------------------------------------------------
 
 Tracking and contributing to an entire Subversion-managed project
@@ -488,7 +488,7 @@ Tracking and contributing to an entire Subversion-managed project
 
 ------------------------------------------------------------------------
 # Clone a repo (like git clone):
-	git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+	git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
 # View all branches and tags you have cloned:
 	git branch -r
 # Reset your master to trunk (or any other branch, replacing 'trunk'
@@ -498,48 +498,48 @@ Tracking and contributing to an entire Subversion-managed project
 # of dcommit/rebase/show-ignore should be the same as above.
 ------------------------------------------------------------------------
 
-The initial 'git-svn clone' can be quite time-consuming
+The initial `git-svn clone` can be quite time-consuming
 (especially for large Subversion repositories). If multiple
 people (or one person with multiple machines) want to use
-git-svn to interact with the same Subversion repository, you can
-do the initial 'git-svn clone' to a repository on a server and
-have each person clone that repository with 'git clone':
+`git-svn` to interact with the same Subversion repository, you can
+do the initial `git-svn clone` to a repository on a server and
+have each person clone that repository with `git-clone`:
 
 ------------------------------------------------------------------------
 # Do the initial import on a server
-	ssh server "cd /pub && git-svn clone http://svn.foo.org/project
+	ssh server "cd /pub && git svn clone http://svn.foo.org/project
 # Clone locally - make sure the refs/remotes/ space matches the server
 	mkdir project
 	cd project
-	git-init
+	git init
 	git remote add origin server:/pub/project
 	git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
 	git fetch
 # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
-	git-svn init http://svn.foo.org/project
+	git svn init http://svn.foo.org/project
 # Pull the latest changes from Subversion
-	git-svn rebase
+	git svn rebase
 ------------------------------------------------------------------------
 
 REBASE VS. PULL/MERGE
 ---------------------
 
-Originally, git-svn recommended that the remotes/git-svn branch be
+Originally, `git-svn` recommended that the 'remotes/git-svn' branch be
 pulled or merged from.  This is because the author favored
-'git-svn set-tree B' to commit a single head rather than the
-'git-svn set-tree A..B' notation to commit multiple commits.
+`git svn set-tree B` to commit a single head rather than the
+`git svn set-tree A..B` notation to commit multiple commits.
 
-If you use 'git-svn set-tree A..B' to commit several diffs and you do
+If you use `git svn set-tree A..B` to commit several diffs and you do
 not have the latest remotes/git-svn merged into my-branch, you should
-use 'git-svn rebase' to update your work branch instead of 'git pull' or
-'git merge'.  'pull/merge' can cause non-linear history to be flattened
+use `git svn rebase` to update your work branch instead of `git pull` or
+`git merge`.  `pull`/`merge' can cause non-linear history to be flattened
 when committing into SVN, which can lead to merge commits reversing
 previous commits in SVN.
 
 DESIGN PHILOSOPHY
 -----------------
 Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result.  While git-svn can track
+with Subversion can be cumbersome as a result.  While `git-svn` can track
 copy history (including branches and tags) for repositories adopting a
 standard layout, it cannot yet represent merge history that happened
 inside git back upstream to SVN users.  Therefore it is advised that
@@ -550,30 +550,30 @@ CAVEATS
 -------
 
 For the sake of simplicity and interoperating with a less-capable system
-(SVN), it is recommended that all git-svn users clone, fetch and dcommit
-directly from the SVN server, and avoid all git-clone/pull/merge/push
+(SVN), it is recommended that all `git-svn` users clone, fetch and dcommit
+directly from the SVN server, and avoid all `git-clone`/`pull`/`merge`/`push`
 operations between git repositories and branches.  The recommended
 method of exchanging code between git branches and users is
-git-format-patch and git-am, or just dcommiting to the SVN repository.
+`git-format-patch` and `git-am`, or just 'dcommit'ing to the SVN repository.
 
-Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
-plan to dcommit from.  Subversion does not represent merges in any
+Running `git-merge` or `git-pull` is NOT recommended on a branch you
+plan to 'dcommit' from.  Subversion does not represent merges in any
 reasonable or useful fashion; so users using Subversion cannot see any
 merges you've made.  Furthermore, if you merge or pull from a git branch
-that is a mirror of an SVN branch, dcommit may commit to the wrong
+that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
 branch.
 
-'git-clone' does not clone branches under the refs/remotes/ hierarchy or
-any git-svn metadata, or config.  So repositories created and managed with
-using git-svn should use rsync(1) for cloning, if cloning is to be done
+`git-clone` does not clone branches under the refs/remotes/ hierarchy or
+any `git-svn` metadata, or config.  So repositories created and managed with
+using `git-svn` should use `rsync` for cloning, if cloning is to be done
 at all.
 
-Since 'dcommit' uses rebase internally, any git branches you git-push to
-before dcommit on will require forcing an overwrite of the existing ref
+Since 'dcommit' uses rebase internally, any git branches you `git-push` to
+before 'dcommit' on will require forcing an overwrite of the existing ref
 on the remote repository.  This is generally considered bad practice,
-see the git-push(1) documentation for details.
+see the linkgit:git-push[1] documentation for details.
 
-Do not use the --amend option of git-commit(1) on a change you've
+Do not use the --amend option of linkgit:git-commit[1] on a change you've
 already dcommitted.  It is considered bad practice to --amend commits
 you've already pushed to a remote repository for other users, and
 dcommit with SVN is analogous to that.
@@ -594,7 +594,7 @@ for git to detect them.
 CONFIGURATION
 -------------
 
-git-svn stores [svn-remote] configuration information in the
+`git-svn` stores [svn-remote] configuration information in the
 repository .git/config file.  It is similar the core git
 [remote] sections except 'fetch' keys do not accept glob
 arguments; but they are instead handled by the 'branches'
@@ -615,8 +615,7 @@ Keep in mind that the '*' (asterisk) wildcard of the local ref
 however the remote wildcard may be anywhere as long as it's own
 independent path component (surrounded by '/' or EOL).   This
 type of configuration is not automatically created by 'init' and
-should be manually entered with a text-editor or using
-linkgit:git-config[1]
+should be manually entered with a text-editor or using `git-config`.
 
 SEE ALSO
 --------
diff --git a/git-symbolic-ref.html b/git-symbolic-ref.html
index 2fefbb66b..548a51517 100644
--- a/git-symbolic-ref.html
+++ b/git-symbolic-ref.html
@@ -272,7 +272,7 @@ git-symbolic-ref(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-symbolic-ref</em> [-q] [-m &lt;reason&gt;] &lt;name&gt; [&lt;ref&gt;]</p>
+<p><em>git symbolic-ref</em> [-q] [-m &lt;reason&gt;] &lt;name&gt; [&lt;ref&gt;]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -325,7 +325,7 @@ or that do not have the <tt>readlink(1)</tt> command, this was a bit
 cumbersome.  On some platforms, <tt>ln -sf</tt> does not even work as
 advertised (horrors).  Therefore symbolic links are now deprecated
 and symbolic refs are used by default.</p>
-<p>git-symbolic-ref will exit with status 0 if the contents of the
+<p><tt>git-symbolic-ref</tt> will exit with status 0 if the contents of the
 symbolic ref were printed correctly, with status 1 if the requested
 name is not a symbolic ref, or 128 if another error occurs.</p>
 </div>
@@ -339,7 +339,7 @@ name is not a symbolic ref, or 128 if another error occurs.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:02 UTC
+Last updated 02-Jul-2008 03:02:04 UTC
 </div>
 </div>
 </body>
diff --git a/git-symbolic-ref.txt b/git-symbolic-ref.txt
index 3d3a059c5..a4962413d 100644
--- a/git-symbolic-ref.txt
+++ b/git-symbolic-ref.txt
@@ -7,7 +7,7 @@ git-symbolic-ref - Read and modify symbolic refs
 
 SYNOPSIS
 --------
-'git-symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
+'git symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
 
 DESCRIPTION
 -----------
@@ -49,7 +49,7 @@ cumbersome.  On some platforms, `ln -sf` does not even work as
 advertised (horrors).  Therefore symbolic links are now deprecated
 and symbolic refs are used by default.
 
-git-symbolic-ref will exit with status 0 if the contents of the
+`git-symbolic-ref` will exit with status 0 if the contents of the
 symbolic ref were printed correctly, with status 1 if the requested
 name is not a symbolic ref, or 128 if another error occurs.
 
diff --git a/git-tag.html b/git-tag.html
index e35afe3a4..ad0f3dcb8 100644
--- a/git-tag.html
+++ b/git-tag.html
@@ -273,10 +273,10 @@ git-tag(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-tag</em> [-a | -s | -u &lt;key-id&gt;] [-f] [-m &lt;msg&gt; | -F &lt;file&gt;]  &lt;name&gt; [&lt;head&gt;]
-<em>git-tag</em> -d &lt;name&gt;&#8230;
-<em>git-tag</em> [-n[&lt;num&gt;]] -l [&lt;pattern&gt;]
-<em>git-tag</em> -v &lt;name&gt;&#8230;</div></div>
+<div class="content"><em>git tag</em> [-a | -s | -u &lt;key-id&gt;] [-f] [-m &lt;msg&gt; | -F &lt;file&gt;]  &lt;name&gt; [&lt;head&gt;]
+<em>git tag</em> -d &lt;name&gt;&#8230;
+<em>git tag</em> [-n[&lt;num&gt;]] -l [&lt;pattern&gt;]
+<em>git tag</em> -v &lt;name&gt;&#8230;</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -394,7 +394,7 @@ GnuPG key for signing.</p>
 </div>
 <h2>CONFIGURATION</h2>
 <div class="sectionbody">
-<p>By default, git-tag in sign-with-default mode (-s) will use your
+<p>By default, <tt>git-tag</tt> in sign-with-default mode (-s) will use your
 committer identity (of the form "Your Name &lt;your@email.address&gt;") to
 find a key.  If you want to use a different default key, you can specify
 it in the repository configuration as follows:</p>
@@ -429,14 +429,14 @@ and be done with it.
 <p>
 The insane thing.
 You really want to call the new version "X" too, <em>even though</em>
-others have already seen the old one. So just use "git tag -f"
+others have already seen the old one. So just use <tt>git-tag -f</tt>
 again, as if you hadn't already published the old one.
 </p>
 </li>
 </ol>
 <p>However, Git does <strong>not</strong> (and it should not) change tags behind
-users back. So if somebody already got the old tag, doing a "git
-pull" on your tree shouldn't just make them overwrite the old
+users back. So if somebody already got the old tag, doing a
+<tt>git-pull</tt> on your tree shouldn't just make them overwrite the old
 one.</p>
 <p>If somebody got a release tag from you, you cannot just change
 the tag for them by updating your own one. This is a big
@@ -482,7 +482,7 @@ from each other do not necessarily want to automatically get
 private anchor point tags from the other person.</p>
 <p>You would notice "please pull" messages on the mailing list says
 repo URL and branch name alone.  This is designed to be easily
-cut&amp;pasted to "git fetch" command line:</p>
+cut&amp;pasted to a <tt>git-fetch</tt> command line:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>Linus, please pull from
@@ -552,7 +552,7 @@ Junio C Hamano &lt;junkio@cox.net&gt; and Chris Wright &lt;chrisw@osdl.org&gt;.<
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:18 UTC
+Last updated 02-Jul-2008 03:02:05 UTC
 </div>
 </div>
 </body>
diff --git a/git-tag.txt b/git-tag.txt
index 8f40f4bf0..1db98e2d0 100644
--- a/git-tag.txt
+++ b/git-tag.txt
@@ -9,10 +9,10 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
 SYNOPSIS
 --------
 [verse]
-'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]  <name> [<head>]
-'git-tag' -d <name>...
-'git-tag' [-n[<num>]] -l [<pattern>]
-'git-tag' -v <name>...
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]  <name> [<head>]
+'git tag' -d <name>...
+'git tag' [-n[<num>]] -l [<pattern>]
+'git tag' -v <name>...
 
 DESCRIPTION
 -----------
@@ -82,7 +82,7 @@ OPTIONS
 
 CONFIGURATION
 -------------
-By default, git-tag in sign-with-default mode (-s) will use your
+By default, `git-tag` in sign-with-default mode (-s) will use your
 committer identity (of the form "Your Name <your@email.address>") to
 find a key.  If you want to use a different default key, you can specify
 it in the repository configuration as follows:
@@ -118,12 +118,12 @@ and be done with it.
 
 . The insane thing.
 You really want to call the new version "X" too, 'even though'
-others have already seen the old one. So just use "git tag -f"
+others have already seen the old one. So just use `git-tag -f`
 again, as if you hadn't already published the old one.
 
 However, Git does *not* (and it should not) change tags behind
-users back. So if somebody already got the old tag, doing a "git
-pull" on your tree shouldn't just make them overwrite the old
+users back. So if somebody already got the old tag, doing a
+`git-pull` on your tree shouldn't just make them overwrite the old
 one.
 
 If somebody got a release tag from you, you cannot just change
@@ -177,7 +177,7 @@ private anchor point tags from the other person.
 
 You would notice "please pull" messages on the mailing list says
 repo URL and branch name alone.  This is designed to be easily
-cut&pasted to "git fetch" command line:
+cut&pasted to a `git-fetch` command line:
 
 ------------
 Linus, please pull from
diff --git a/git-tar-tree.html b/git-tar-tree.html
index a0651df4a..a65ac83eb 100644
--- a/git-tar-tree.html
+++ b/git-tar-tree.html
@@ -272,7 +272,7 @@ git-tar-tree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-tar-tree</em> [--remote=&lt;repo&gt;] &lt;tree-ish&gt; [ &lt;base&gt; ]</p>
+<p><em>git tar-tree</em> [--remote=&lt;repo&gt;] &lt;tree-ish&gt; [ &lt;base&gt; ]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -281,12 +281,12 @@ option instead (and move the &lt;base&gt; argument to <tt>--prefix=base/</tt>).<
 <p>Creates a tar archive containing the tree structure for the named tree.
 When &lt;base&gt; is specified it is added as a leading path to the files in the
 generated tar archive.</p>
-<p>git-tar-tree behaves differently when given a tree ID versus when given
+<p><tt>git-tar-tree</tt> behaves differently when given a tree ID versus when given
 a commit ID or tag ID.  In the first case the current time is used as
 modification time of each file in the archive.  In the latter case the
 commit time as recorded in the referenced commit object is used instead.
 Additionally the commit ID is stored in a global extended pax header.
-It can be extracted using git-get-tar-commit-id.</p>
+It can be extracted using <tt>git-get-tar-commit-id</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -399,7 +399,7 @@ git tar-tree HEAD:Documentation/ git-docs &gt; git-1.4.0-docs.tar
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:20 UTC
+Last updated 02-Jul-2008 03:02:05 UTC
 </div>
 </div>
 </body>
diff --git a/git-tar-tree.txt b/git-tar-tree.txt
index 74ed06525..b3097aa79 100644
--- a/git-tar-tree.txt
+++ b/git-tar-tree.txt
@@ -8,7 +8,7 @@ git-tar-tree - Create a tar archive of the files in the named tree object
 
 SYNOPSIS
 --------
-'git-tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
+'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
 
 DESCRIPTION
 -----------
@@ -19,12 +19,12 @@ Creates a tar archive containing the tree structure for the named tree.
 When <base> is specified it is added as a leading path to the files in the
 generated tar archive.
 
-git-tar-tree behaves differently when given a tree ID versus when given
+`git-tar-tree` behaves differently when given a tree ID versus when given
 a commit ID or tag ID.  In the first case the current time is used as
 modification time of each file in the archive.  In the latter case the
 commit time as recorded in the referenced commit object is used instead.
 Additionally the commit ID is stored in a global extended pax header.
-It can be extracted using git-get-tar-commit-id.
+It can be extracted using `git-get-tar-commit-id`.
 
 OPTIONS
 -------
diff --git a/git-tools.html b/git-tools.html
index 609b4c33f..239643abb 100644
--- a/git-tools.html
+++ b/git-tools.html
@@ -438,7 +438,7 @@ comprehensive list.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:36 UTC
+Last updated 02-Jul-2008 03:02:15 UTC
 </div>
 </div>
 </body>
diff --git a/git-unpack-file.html b/git-unpack-file.html
index f106149a9..c2a93cbd1 100644
--- a/git-unpack-file.html
+++ b/git-unpack-file.html
@@ -272,7 +272,7 @@ git-unpack-file(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-unpack-file</em> &lt;blob&gt;</p>
+<p><em>git unpack-file</em> &lt;blob&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -307,7 +307,7 @@ returns the name of the temporary file in the following format:
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:20 UTC
+Last updated 02-Jul-2008 03:02:05 UTC
 </div>
 </div>
 </body>
diff --git a/git-unpack-file.txt b/git-unpack-file.txt
index d0552b2c7..995db9fea 100644
--- a/git-unpack-file.txt
+++ b/git-unpack-file.txt
@@ -9,7 +9,7 @@ git-unpack-file - Creates a temporary file with a blob's contents
 
 SYNOPSIS
 --------
-'git-unpack-file' <blob>
+'git unpack-file' <blob>
 
 DESCRIPTION
 -----------
diff --git a/git-unpack-objects.html b/git-unpack-objects.html
index 211282d2c..77b0791ce 100644
--- a/git-unpack-objects.html
+++ b/git-unpack-objects.html
@@ -272,7 +272,7 @@ git-unpack-objects(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-unpack-objects</em> [-n] [-q] [-r] [--strict] &lt;pack-file</p>
+<p><em>git unpack-objects</em> [-n] [-q] [-r] [--strict] &lt;pack-file</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -282,7 +282,7 @@ the objects contained within and writing them into the repository in
 <p>Objects that already exist in the repository will <strong>not</strong> be unpacked
 from the pack-file.  Therefore, nothing will be unpacked if you use
 this command on a pack-file that exists within the target repository.</p>
-<p>Please see the <tt>git-repack</tt> documentation for options to generate
+<p>See <a href="git-repack.html">git-repack(1)</a> for options to generate
 new packs and replace existing ones.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -341,7 +341,7 @@ new packs and replace existing ones.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:20 UTC
+Last updated 02-Jul-2008 03:02:06 UTC
 </div>
 </div>
 </body>
diff --git a/git-unpack-objects.txt b/git-unpack-objects.txt
index b9c4279a8..36d103805 100644
--- a/git-unpack-objects.txt
+++ b/git-unpack-objects.txt
@@ -8,7 +8,7 @@ git-unpack-objects - Unpack objects from a packed archive
 
 SYNOPSIS
 --------
-'git-unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
+'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
 
 
 DESCRIPTION
@@ -21,7 +21,7 @@ Objects that already exist in the repository will *not* be unpacked
 from the pack-file.  Therefore, nothing will be unpacked if you use
 this command on a pack-file that exists within the target repository.
 
-Please see the `git-repack` documentation for options to generate
+See linkgit:git-repack[1] for options to generate
 new packs and replace existing ones.
 
 OPTIONS
diff --git a/git-update-index.html b/git-update-index.html
index 30c972e5a..cc6b77816 100644
--- a/git-update-index.html
+++ b/git-update-index.html
@@ -273,7 +273,7 @@ git-update-index(1) Manual Page
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
-<div class="content"><em>git-update-index</em>
+<div class="content"><em>git update-index</em>
              [--add] [--remove | --force-remove] [--replace]
              [--refresh] [-q] [--unmerged] [--ignore-missing]
              [--cacheinfo &lt;mode&gt; &lt;object&gt; &lt;file&gt;]*
@@ -293,7 +293,7 @@ into the index and any <em>unmerged</em> or <em>needs updating</em> state is
 cleared.</p>
 <p>See also <a href="git-add.html">git-add(1)</a> for a more user-friendly way to do some of
 the most common operations on the index.</p>
-<p>The way "git-update-index" handles files it is told about can be modified
+<p>The way <tt>git-update-index</tt> handles files it is told about can be modified
 using the various options:</p>
 </div>
 <h2>OPTIONS</h2>
@@ -335,7 +335,7 @@ using the various options:</p>
 <p>
         Quiet.  If --refresh finds that the index needs an update, the
         default behavior is to error out.  This option makes
-        git-update-index continue anyway.
+        <tt>git-update-index</tt> continue anyway.
 </p>
 </dd>
 </dl>
@@ -349,7 +349,7 @@ using the various options:</p>
 <dd>
 <p>
         If --refresh finds unmerged changes in the index, the default
-        behavior is to error out.  This option makes git-update-index
+        behavior is to error out.  This option makes <tt>git-update-index</tt>
         continue anyway.
 </p>
 </dd>
@@ -451,7 +451,7 @@ using the various options:</p>
 <dd>
 <p>
         By default, when a file <tt>path</tt> exists in the index,
-        git-update-index refuses an attempt to add <tt>path/file</tt>.
+        <tt>git-update-index</tt> refuses an attempt to add <tt>path/file</tt>.
         Similarly if a file <tt>path/file</tt> exists, a file <tt>path</tt>
         cannot be added.  With --replace flag, existing entries
         that conflicts with the entry being added are
@@ -514,7 +514,7 @@ up-to-date for mode/content changes. But what it <strong>does</strong> do is to
 "re-match" the stat information of a file with the index, so that you
 can refresh the index for a file that hasn't been changed but where
 the stat entry is out of date.</p>
-<p>For example, you'd want to do this after doing a "git-read-tree", to link
+<p>For example, you'd want to do this after doing a <tt>git-read-tree</tt>, to link
 up the stat index details with the proper files.</p>
 </div>
 <h2>Using --cacheinfo or --info-only</h2>
@@ -525,7 +525,7 @@ merging.</p>
 <p>To pretend you have a file with mode and sha1 at path, say:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-update-index --cacheinfo mode sha1 path</tt></pre>
+<pre><tt>$ git update-index --cacheinfo mode sha1 path</tt></pre>
 </div></div>
 <p><em>--info-only</em> is used to register files without placing them in the object
 database.  This is useful for status-only repositories.</p>
@@ -554,7 +554,7 @@ back on 3-way merge.</p>
 <p>
 mode SP type SP sha1          TAB path
 </p>
-<p>The second format is to stuff git-ls-tree output
+<p>The second format is to stuff <tt>git-ls-tree</tt> output
 into the index file.</p>
 </li>
 <li>
@@ -562,7 +562,7 @@ into the index file.</p>
 mode         SP sha1 SP stage TAB path
 </p>
 <p>This format is to put higher order stages into the
-index file and matches git-ls-files --stage output.</p>
+index file and matches <tt>git-ls-files --stage</tt> output.</p>
 </li>
 </ol>
 <p>To place a higher stage entry to the index, the path should
@@ -611,13 +611,13 @@ tree files, you have to explicitly tell git about it by dropping
 <p>In order to set "assume unchanged" bit, use <tt>--assume-unchanged</tt>
 option.  To unset, use <tt>--no-assume-unchanged</tt>.</p>
 <p>The command looks at <tt>core.ignorestat</tt> configuration variable.  When
-this is true, paths updated with <tt>git-update-index paths&#8230;</tt> and
+this is true, paths updated with <tt>git update-index paths&#8230;</tt> and
 paths updated with other git commands that update both index and
 working tree (e.g. <tt>git-apply --index</tt>, <tt>git-checkout-index -u</tt>,
 and <tt>git-read-tree -u</tt>) are automatically marked as "assume
 unchanged".  Note that "assume unchanged" bit is <strong>not</strong> set if
-<tt>git-update-index --refresh</tt> finds the working tree file matches
-the index (use <tt>git-update-index --really-refresh</tt> if you want
+<tt>git update-index --refresh</tt> finds the working tree file matches
+the index (use <tt>git update-index --really-refresh</tt> if you want
 to mark them as "assume unchanged").</p>
 </div>
 <h2>Examples</h2>
@@ -625,7 +625,7 @@ to mark them as "assume unchanged").</p>
 <p>To update and refresh only the files already checked out:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-checkout-index -n -f -a &amp;&amp; git-update-index --ignore-missing --refresh</tt></pre>
+<pre><tt>$ git checkout-index -n -f -a &amp;&amp; git update-index --ignore-missing --refresh</tt></pre>
 </div></div>
 <dl>
 <dt>
@@ -733,7 +733,7 @@ from symbolic link to regular file.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:03 UTC
+Last updated 02-Jul-2008 03:02:06 UTC
 </div>
 </div>
 </body>
diff --git a/git-update-index.txt b/git-update-index.txt
index bbb0a6ad5..999e9a7c8 100644
--- a/git-update-index.txt
+++ b/git-update-index.txt
@@ -9,7 +9,7 @@ git-update-index - Register file contents in the working tree to the index
 SYNOPSIS
 --------
 [verse]
-'git-update-index'
+'git update-index'
 	     [--add] [--remove | --force-remove] [--replace]
 	     [--refresh] [-q] [--unmerged] [--ignore-missing]
 	     [--cacheinfo <mode> <object> <file>]\*
@@ -31,7 +31,7 @@ cleared.
 See also linkgit:git-add[1] for a more user-friendly way to do some of
 the most common operations on the index.
 
-The way "git-update-index" handles files it is told about can be modified
+The way `git-update-index` handles files it is told about can be modified
 using the various options:
 
 OPTIONS
@@ -53,7 +53,7 @@ OPTIONS
 -q::
         Quiet.  If --refresh finds that the index needs an update, the
         default behavior is to error out.  This option makes
-        git-update-index continue anyway.
+	`git-update-index` continue anyway.
 
 --ignore-submodules:
 	Do not try to update submodules.  This option is only respected
@@ -61,7 +61,7 @@ OPTIONS
 
 --unmerged::
         If --refresh finds unmerged changes in the index, the default
-        behavior is to error out.  This option makes git-update-index
+	behavior is to error out.  This option makes `git-update-index`
         continue anyway.
 
 --ignore-missing::
@@ -109,7 +109,7 @@ OPTIONS
 
 --replace::
 	By default, when a file `path` exists in the index,
-	git-update-index refuses an attempt to add `path/file`.
+	`git-update-index` refuses an attempt to add `path/file`.
 	Similarly if a file `path/file` exists, a file `path`
 	cannot be added.  With --replace flag, existing entries
 	that conflicts with the entry being added are
@@ -145,7 +145,7 @@ up-to-date for mode/content changes. But what it *does* do is to
 can refresh the index for a file that hasn't been changed but where
 the stat entry is out of date.
 
-For example, you'd want to do this after doing a "git-read-tree", to link
+For example, you'd want to do this after doing a `git-read-tree`, to link
 up the stat index details with the proper files.
 
 Using --cacheinfo or --info-only
@@ -157,7 +157,7 @@ merging.
 To pretend you have a file with mode and sha1 at path, say:
 
 ----------------
-$ git-update-index --cacheinfo mode sha1 path
+$ git update-index --cacheinfo mode sha1 path
 ----------------
 
 '--info-only' is used to register files without placing them in the object
@@ -186,13 +186,13 @@ back on 3-way merge.
 
     . mode SP type SP sha1          TAB path
 +
-The second format is to stuff git-ls-tree output
+The second format is to stuff `git-ls-tree` output
 into the index file.
 
     . mode         SP sha1 SP stage TAB path
 +
 This format is to put higher order stages into the
-index file and matches git-ls-files --stage output.
+index file and matches `git-ls-files --stage` output.
 
 To place a higher stage entry to the index, the path should
 first be removed by feeding a mode=0 entry for the path, and
@@ -247,13 +247,13 @@ In order to set "assume unchanged" bit, use `--assume-unchanged`
 option.  To unset, use `--no-assume-unchanged`.
 
 The command looks at `core.ignorestat` configuration variable.  When
-this is true, paths updated with `git-update-index paths...` and
+this is true, paths updated with `git update-index paths...` and
 paths updated with other git commands that update both index and
 working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
 and `git-read-tree -u`) are automatically marked as "assume
 unchanged".  Note that "assume unchanged" bit is *not* set if
-`git-update-index --refresh` finds the working tree file matches
-the index (use `git-update-index --really-refresh` if you want
+`git update-index --refresh` finds the working tree file matches
+the index (use `git update-index --really-refresh` if you want
 to mark them as "assume unchanged").
 
 
@@ -262,7 +262,7 @@ Examples
 To update and refresh only the files already checked out:
 
 ----------------
-$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
 ----------------
 
 On an inefficient filesystem with `core.ignorestat` set::
diff --git a/git-update-ref.html b/git-update-ref.html
index 4cab62f65..5cd132f49 100644
--- a/git-update-ref.html
+++ b/git-update-ref.html
@@ -272,17 +272,17 @@ git-update-ref(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-update-ref</em> [-m &lt;reason&gt;] (-d &lt;ref&gt; [&lt;oldvalue&gt;] | [--no-deref] &lt;ref&gt; &lt;newvalue&gt; [&lt;oldvalue&gt;])</p>
+<p><em>git update-ref</em> [-m &lt;reason&gt;] (-d &lt;ref&gt; [&lt;oldvalue&gt;] | [--no-deref] &lt;ref&gt; &lt;newvalue&gt; [&lt;oldvalue&gt;])</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Given two arguments, stores the &lt;newvalue&gt; in the &lt;ref&gt;, possibly
-dereferencing the symbolic refs.  E.g. <tt>git-update-ref HEAD
+dereferencing the symbolic refs.  E.g. <tt>git update-ref HEAD
 &lt;newvalue&gt;</tt> updates the current branch head to the new object.</p>
 <p>Given three arguments, stores the &lt;newvalue&gt; in the &lt;ref&gt;,
 possibly dereferencing the symbolic refs, after verifying that
 the current value of the &lt;ref&gt; matches &lt;oldvalue&gt;.
-E.g. <tt>git-update-ref refs/heads/master &lt;newvalue&gt; &lt;oldvalue&gt;</tt>
+E.g. <tt>git update-ref refs/heads/master &lt;newvalue&gt; &lt;oldvalue&gt;</tt>
 updates the master branch head to &lt;newvalue&gt; only if its current
 value is &lt;oldvalue&gt;.  You can specify 40 "0" or an empty string
 as &lt;oldvalue&gt; to make sure that the ref you are creating does
@@ -302,7 +302,7 @@ the result of following the symbolic pointers.</p>
 <p>In general, using</p>
 <div class="literalblock">
 <div class="content">
-<pre><tt>git-update-ref HEAD "$head"</tt></pre>
+<pre><tt>git update-ref HEAD "$head"</tt></pre>
 </div></div>
 <p>should be a _lot_ safer than doing</p>
 <div class="literalblock">
@@ -321,7 +321,7 @@ still contains &lt;oldvalue&gt;.</p>
 <h2>Logging Updates</h2>
 <div class="sectionbody">
 <p>If config parameter "core.logAllRefUpdates" is true or the file
-"$GIT_DIR/logs/&lt;ref&gt;" exists then <tt>git-update-ref</tt> will append
+"$GIT_DIR/logs/&lt;ref&gt;" exists then <tt>git update-ref</tt> will append
 a line to the log file "$GIT_DIR/logs/&lt;ref&gt;" (dereferencing all
 symbolic refs before creating the log name) describing the change
 in ref value.  Log lines are formatted as:</p>
@@ -360,7 +360,7 @@ or does not have committer information available.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:36 UTC
+Last updated 02-Jul-2008 03:02:06 UTC
 </div>
 </div>
 </body>
diff --git a/git-update-ref.txt b/git-update-ref.txt
index bae2c8b7e..9639f705a 100644
--- a/git-update-ref.txt
+++ b/git-update-ref.txt
@@ -7,18 +7,18 @@ git-update-ref - Update the object name stored in a ref safely
 
 SYNOPSIS
 --------
-'git-update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
+'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
 
 DESCRIPTION
 -----------
 Given two arguments, stores the <newvalue> in the <ref>, possibly
-dereferencing the symbolic refs.  E.g. `git-update-ref HEAD
+dereferencing the symbolic refs.  E.g. `git update-ref HEAD
 <newvalue>` updates the current branch head to the new object.
 
 Given three arguments, stores the <newvalue> in the <ref>,
 possibly dereferencing the symbolic refs, after verifying that
 the current value of the <ref> matches <oldvalue>.
-E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
+E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>`
 updates the master branch head to <newvalue> only if its current
 value is <oldvalue>.  You can specify 40 "0" or an empty string
 as <oldvalue> to make sure that the ref you are creating does
@@ -41,7 +41,7 @@ the result of following the symbolic pointers.
 
 In general, using
 
-	git-update-ref HEAD "$head"
+	git update-ref HEAD "$head"
 
 should be a _lot_ safer than doing
 
@@ -61,7 +61,7 @@ still contains <oldvalue>.
 Logging Updates
 ---------------
 If config parameter "core.logAllRefUpdates" is true or the file
-"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
+"$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
 a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
 symbolic refs before creating the log name) describing the change
 in ref value.  Log lines are formatted as:
diff --git a/git-update-server-info.html b/git-update-server-info.html
index 4568ee9f6..d46bff6f1 100644
--- a/git-update-server-info.html
+++ b/git-update-server-info.html
@@ -272,7 +272,7 @@ git-update-server-info(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-update-server-info</em> [--force]</p>
+<p><em>git update-server-info</em> [--force]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -301,7 +301,7 @@ generates such auxiliary files.</p>
 <h2>OUTPUT</h2>
 <div class="sectionbody">
 <p>Currently the command updates the following files.  Please see
-<a href="gitrepository-layout.html">gitrepository-layout(5)</a>[repository-layout] for description of
+<a href="gitrepository-layout.html">gitrepository-layout(5)</a> for description of
 what they are for:</p>
 <ul>
 <li>
@@ -335,7 +335,7 @@ info/refs file unless <tt>--force</tt> flag is given.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:03 UTC
+Last updated 02-Jul-2008 03:02:06 UTC
 </div>
 </div>
 </body>
diff --git a/git-update-server-info.txt b/git-update-server-info.txt
index d21be41d0..bc1207a31 100644
--- a/git-update-server-info.txt
+++ b/git-update-server-info.txt
@@ -8,7 +8,7 @@ git-update-server-info - Update auxiliary info file to help dumb servers
 
 SYNOPSIS
 --------
-'git-update-server-info' [--force]
+'git update-server-info' [--force]
 
 DESCRIPTION
 -----------
@@ -31,7 +31,7 @@ OUTPUT
 ------
 
 Currently the command updates the following files.  Please see
-linkgit:gitrepository-layout[5][repository-layout] for description of
+linkgit:gitrepository-layout[5] for description of
 what they are for:
 
 * objects/info/packs
diff --git a/git-upload-archive.html b/git-upload-archive.html
index f9f5384b7..3d35ea458 100644
--- a/git-upload-archive.html
+++ b/git-upload-archive.html
@@ -272,14 +272,14 @@ git-upload-archive(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-upload-archive</em> &lt;directory&gt;</p>
+<p><em>git upload-archive</em> &lt;directory&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Invoked by <em>git-archive --remote</em> and sends a generated archive to the
 other end over the git protocol.</p>
 <p>This command is usually not invoked directly by the end user.  The UI
-for the protocol is on the <em>git-archive</em> side, and the program pair
+for the protocol is on the <tt>git-archive</tt> side, and the program pair
 is meant to be used to get an archive from a remote repository.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -309,7 +309,7 @@ is meant to be used to get an archive from a remote repository.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:22 UTC
+Last updated 02-Jul-2008 03:02:07 UTC
 </div>
 </div>
 </body>
diff --git a/git-upload-archive.txt b/git-upload-archive.txt
index e49f68f68..526e5bdd2 100644
--- a/git-upload-archive.txt
+++ b/git-upload-archive.txt
@@ -8,7 +8,7 @@ git-upload-archive - Send archive back to git-archive
 
 SYNOPSIS
 --------
-'git-upload-archive' <directory>
+'git upload-archive' <directory>
 
 DESCRIPTION
 -----------
@@ -16,7 +16,7 @@ Invoked by 'git-archive --remote' and sends a generated archive to the
 other end over the git protocol.
 
 This command is usually not invoked directly by the end user.  The UI
-for the protocol is on the 'git-archive' side, and the program pair
+for the protocol is on the `git-archive` side, and the program pair
 is meant to be used to get an archive from a remote repository.
 
 OPTIONS
diff --git a/git-upload-pack.html b/git-upload-pack.html
index 5293f3127..8cba080e0 100644
--- a/git-upload-pack.html
+++ b/git-upload-pack.html
@@ -272,16 +272,16 @@ git-upload-pack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-upload-pack</em> [--strict] [--timeout=&lt;n&gt;] &lt;directory&gt;</p>
+<p><em>git upload-pack</em> [--strict] [--timeout=&lt;n&gt;] &lt;directory&gt;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Invoked by <em>git-fetch-pack</em>, learns what
+<p>Invoked by <tt>git-fetch-pack</tt>, learns what
 objects the other side is missing, and sends them after packing.</p>
 <p>This command is usually not invoked directly by the end user.
-The UI for the protocol is on the <em>git-fetch-pack</em> side, and the
+The UI for the protocol is on the <tt>git-fetch-pack</tt> side, and the
 program pair is meant to be used to pull updates from a remote
-repository.  For push operations, see <em>git-send-pack</em>.</p>
+repository.  For push operations, see <tt>git-send-pack</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -326,7 +326,7 @@ repository.  For push operations, see <em>git-send-pack</em>.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:04 UTC
+Last updated 02-Jul-2008 03:02:07 UTC
 </div>
 </div>
 </body>
diff --git a/git-upload-pack.txt b/git-upload-pack.txt
index bac465e13..52724d4c6 100644
--- a/git-upload-pack.txt
+++ b/git-upload-pack.txt
@@ -8,17 +8,17 @@ git-upload-pack - Send objects packed back to git-fetch-pack
 
 SYNOPSIS
 --------
-'git-upload-pack' [--strict] [--timeout=<n>] <directory>
+'git upload-pack' [--strict] [--timeout=<n>] <directory>
 
 DESCRIPTION
 -----------
-Invoked by 'git-fetch-pack', learns what
+Invoked by `git-fetch-pack`, learns what
 objects the other side is missing, and sends them after packing.
 
 This command is usually not invoked directly by the end user.
-The UI for the protocol is on the 'git-fetch-pack' side, and the
+The UI for the protocol is on the `git-fetch-pack` side, and the
 program pair is meant to be used to pull updates from a remote
-repository.  For push operations, see 'git-send-pack'.
+repository.  For push operations, see `git-send-pack`.
 
 
 OPTIONS
diff --git a/git-var.html b/git-var.html
index c4c25392b..e2eea383e 100644
--- a/git-var.html
+++ b/git-var.html
@@ -272,7 +272,7 @@ git-var(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-var</em> [ -l | &lt;variable&gt; ]</p>
+<p><em>git var</em> [ -l | &lt;variable&gt; ]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -298,7 +298,7 @@ git-var(1) Manual Page
 <div class="sectionbody">
 <div class="literalblock">
 <div class="content">
-<pre><tt>$ git-var GIT_AUTHOR_IDENT
+<pre><tt>$ git var GIT_AUTHOR_IDENT
 Eric W. Biederman &lt;ebiederm@lnxi.com&gt; 1121223278 -0600</tt></pre>
 </div></div>
 </div>
@@ -372,7 +372,7 @@ Your sysadmin must hate you!
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:22 UTC
+Last updated 02-Jul-2008 03:02:07 UTC
 </div>
 </div>
 </body>
diff --git a/git-var.txt b/git-var.txt
index 67e8e1f93..10d1e19cc 100644
--- a/git-var.txt
+++ b/git-var.txt
@@ -8,7 +8,7 @@ git-var - Show a git logical variable
 
 SYNOPSIS
 --------
-'git-var' [ -l | <variable> ]
+'git var' [ -l | <variable> ]
 
 DESCRIPTION
 -----------
@@ -24,7 +24,7 @@ OPTIONS
 
 EXAMPLE
 --------
-	$ git-var GIT_AUTHOR_IDENT
+	$ git var GIT_AUTHOR_IDENT
 	Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
 
 
diff --git a/git-verify-pack.html b/git-verify-pack.html
index 9290c2daf..1cb36b722 100644
--- a/git-verify-pack.html
+++ b/git-verify-pack.html
@@ -272,12 +272,12 @@ git-verify-pack(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-verify-pack</em> [-v] [--] &lt;pack&gt;.idx &#8230;</p>
+<p><em>git verify-pack</em> [-v] [--] &lt;pack&gt;.idx &#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Reads given idx file for packed git archive created with
-git-pack-objects command and verifies idx file and the
+<p>Reads given idx file for packed git archive created with the
+<tt>git-pack-objects</tt> command and verifies idx file and the
 corresponding pack file.</p>
 </div>
 <h2>OPTIONS</h2>
@@ -338,7 +338,7 @@ corresponding pack file.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:23 UTC
+Last updated 02-Jul-2008 03:02:07 UTC
 </div>
 </div>
 </body>
diff --git a/git-verify-pack.txt b/git-verify-pack.txt
index 478f23699..4d95c6c89 100644
--- a/git-verify-pack.txt
+++ b/git-verify-pack.txt
@@ -8,13 +8,13 @@ git-verify-pack - Validate packed git archive files
 
 SYNOPSIS
 --------
-'git-verify-pack' [-v] [--] <pack>.idx ...
+'git verify-pack' [-v] [--] <pack>.idx ...
 
 
 DESCRIPTION
 -----------
-Reads given idx file for packed git archive created with
-git-pack-objects command and verifies idx file and the
+Reads given idx file for packed git archive created with the
+`git-pack-objects` command and verifies idx file and the
 corresponding pack file.
 
 OPTIONS
diff --git a/git-verify-tag.html b/git-verify-tag.html
index 55ca0ab18..b0bcaed01 100644
--- a/git-verify-tag.html
+++ b/git-verify-tag.html
@@ -272,11 +272,11 @@ git-verify-tag(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-verify-tag</em> &lt;tag&gt;&#8230;</p>
+<p><em>git verify-tag</em> &lt;tag&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Validates the gpg signature created by git-tag.</p>
+<p>Validates the gpg signature created by <tt>git-tag</tt>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
@@ -305,7 +305,7 @@ git-verify-tag(1) Manual Page
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:23 UTC
+Last updated 02-Jul-2008 03:02:07 UTC
 </div>
 </div>
 </body>
diff --git a/git-verify-tag.txt b/git-verify-tag.txt
index dffba8906..de4a89a10 100644
--- a/git-verify-tag.txt
+++ b/git-verify-tag.txt
@@ -7,11 +7,11 @@ git-verify-tag - Check the GPG signature of tags
 
 SYNOPSIS
 --------
-'git-verify-tag' <tag>...
+'git verify-tag' <tag>...
 
 DESCRIPTION
 -----------
-Validates the gpg signature created by git-tag.
+Validates the gpg signature created by `git-tag`.
 
 OPTIONS
 -------
diff --git a/git-web--browse.html b/git-web--browse.html
index b7a27f15d..fe72da313 100644
--- a/git-web--browse.html
+++ b/git-web--browse.html
@@ -272,7 +272,7 @@ git-web--browse(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-web--browse</em> [OPTIONS] URL/FILE &#8230;</p>
+<p><em>git web--browse</em> [OPTIONS] URL/FILE &#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -374,13 +374,13 @@ configuration variable if the former is not used.</p>
 <p>You can explicitly provide a full path to your preferred browser by
 setting the configuration variable <em>browser.&lt;tool&gt;.path</em>. For example,
 you can configure the absolute path to firefox by setting
-<em>browser.firefox.path</em>. Otherwise, <em>git-web--browse</em> assumes the tool
+<em>browser.firefox.path</em>. Otherwise, <tt>git-web--browse</tt> assumes the tool
 is available in PATH.</p>
 <h3>browser.&lt;tool&gt;.cmd</h3>
 <p>When the browser, specified by options or configuration variables, is
 not among the supported ones, then the corresponding
 <em>browser.&lt;tool&gt;.cmd</em> configuration variable will be looked up. If this
-variable exists then "git web--browse" will treat the specified tool
+variable exists then <tt>git-web--browse</tt> will treat the specified tool
 as a custom command and will use a shell eval to run the command with
 the URLs passed as arguments.</p>
 </div>
@@ -402,7 +402,7 @@ the following:</p>
         [browser "konq"]
                 cmd = A_PATH_TO/konqueror</tt></pre>
 </div></div>
-<h3>Note about git config --global</h3>
+<h3>Note about git-config --global</h3>
 <p>Note that these configuration variables should probably be set using
 the <em>--global</em> flag, for example like this:</p>
 <div class="listingblock">
@@ -415,7 +415,7 @@ See <a href="git-config.html">git-config(1)</a> for more information about this.
 <h2>Author</h2>
 <div class="sectionbody">
 <p>Written by Christian Couder &lt;chriscool@tuxfamily.org&gt; and the git-list
-&lt;git@vger.kernel.org&gt;, based on git-mergetool by Theodore Y. Ts'o.</p>
+&lt;git@vger.kernel.org&gt;, based on <tt>git-mergetool</tt> by Theodore Y. Ts'o.</p>
 </div>
 <h2>Documentation</h2>
 <div class="sectionbody">
@@ -428,7 +428,7 @@ git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:04 UTC
+Last updated 02-Jul-2008 03:02:08 UTC
 </div>
 </div>
 </body>
diff --git a/git-web--browse.txt b/git-web--browse.txt
index e80a7c1cc..fefa6fd38 100644
--- a/git-web--browse.txt
+++ b/git-web--browse.txt
@@ -7,7 +7,7 @@ git-web--browse - git helper script to launch a web browser
 
 SYNOPSIS
 --------
-'git-web--browse' [OPTIONS] URL/FILE ...
+'git web--browse' [OPTIONS] URL/FILE ...
 
 DESCRIPTION
 -----------
@@ -61,7 +61,7 @@ browser.<tool>.path
 You can explicitly provide a full path to your preferred browser by
 setting the configuration variable 'browser.<tool>.path'. For example,
 you can configure the absolute path to firefox by setting
-'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool
+'browser.firefox.path'. Otherwise, `git-web--browse` assumes the tool
 is available in PATH.
 
 browser.<tool>.cmd
@@ -70,7 +70,7 @@ browser.<tool>.cmd
 When the browser, specified by options or configuration variables, is
 not among the supported ones, then the corresponding
 'browser.<tool>.cmd' configuration variable will be looked up. If this
-variable exists then "git web--browse" will treat the specified tool
+variable exists then `git-web--browse` will treat the specified tool
 as a custom command and will use a shell eval to run the command with
 the URLs passed as arguments.
 
@@ -96,7 +96,7 @@ the following:
 		cmd = A_PATH_TO/konqueror
 ------------------------------------------------
 
-Note about git config --global
+Note about git-config --global
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Note that these configuration variables should probably be set using
@@ -112,7 +112,7 @@ See linkgit:git-config[1] for more information about this.
 Author
 ------
 Written by Christian Couder <chriscool@tuxfamily.org> and the git-list
-<git@vger.kernel.org>, based on git-mergetool by Theodore Y. Ts'o.
+<git@vger.kernel.org>, based on `git-mergetool` by Theodore Y. Ts'o.
 
 Documentation
 -------------
diff --git a/git-whatchanged.html b/git-whatchanged.html
index 7d0836a20..47989e5eb 100644
--- a/git-whatchanged.html
+++ b/git-whatchanged.html
@@ -272,13 +272,13 @@ git-whatchanged(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-whatchanged</em> &lt;option&gt;&#8230;</p>
+<p><em>git whatchanged</em> &lt;option&gt;&#8230;</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Shows commit logs and diff output each commit introduces.  The
-command internally invokes <em>git-rev-list</em> piped to
-<em>git-diff-tree</em>, and takes command line options for both of
+command internally invokes <tt>git-rev-list</tt> piped to
+<tt>git-diff-tree</tt>, and takes command line options for both of
 these commands.</p>
 <p>This manual page describes only the most frequently used options.</p>
 </div>
@@ -696,7 +696,7 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
 <div class="sectionbody">
 <dl>
 <dt>
-git-whatchanged -p v2.6.12.. include/scsi drivers/scsi
+git whatchanged -p v2.6.12.. include/scsi drivers/scsi
 </dt>
 <dd>
 <p>
@@ -705,7 +705,7 @@ git-whatchanged -p v2.6.12.. include/scsi drivers/scsi
 </p>
 </dd>
 <dt>
-git-whatchanged --since="2 weeks ago" -- gitk
+git whatchanged --since="2 weeks ago" -- gitk
 </dt>
 <dd>
 <p>
@@ -731,7 +731,7 @@ Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:45 UTC
+Last updated 02-Jul-2008 03:02:08 UTC
 </div>
 </div>
 </body>
diff --git a/git-whatchanged.txt b/git-whatchanged.txt
index f5d39c787..3b0ea2c59 100644
--- a/git-whatchanged.txt
+++ b/git-whatchanged.txt
@@ -8,13 +8,13 @@ git-whatchanged - Show logs with difference each commit introduces
 
 SYNOPSIS
 --------
-'git-whatchanged' <option>...
+'git whatchanged' <option>...
 
 DESCRIPTION
 -----------
 Shows commit logs and diff output each commit introduces.  The
-command internally invokes 'git-rev-list' piped to
-'git-diff-tree', and takes command line options for both of
+command internally invokes `git-rev-list` piped to
+`git-diff-tree`, and takes command line options for both of
 these commands.
 
 This manual page describes only the most frequently used options.
@@ -52,12 +52,12 @@ include::pretty-formats.txt[]
 
 Examples
 --------
-git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+git whatchanged -p v2.6.12.. include/scsi drivers/scsi::
 
 	Show as patches the commits since version 'v2.6.12' that changed
 	any file in the include/scsi or drivers/scsi subdirectories
 
-git-whatchanged --since="2 weeks ago" \-- gitk::
+git whatchanged --since="2 weeks ago" \-- gitk::
 
 	Show the changes during the last two weeks to the file 'gitk'.
 	The "--" is necessary to avoid confusion with the *branch* named
diff --git a/git-write-tree.html b/git-write-tree.html
index 4a74b3ed1..55a99e91d 100644
--- a/git-write-tree.html
+++ b/git-write-tree.html
@@ -272,7 +272,7 @@ git-write-tree(1) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p><em>git-write-tree</em> [--missing-ok] [--prefix=&lt;prefix&gt;/]</p>
+<p><em>git write-tree</em> [--missing-ok] [--prefix=&lt;prefix&gt;/]</p>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
@@ -323,7 +323,7 @@ now, you need to have done a <tt>git-update-index</tt> phase before you did the
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:25 UTC
+Last updated 02-Jul-2008 03:02:08 UTC
 </div>
 </div>
 </body>
diff --git a/git-write-tree.txt b/git-write-tree.txt
index 8744f6535..19d979bcc 100644
--- a/git-write-tree.txt
+++ b/git-write-tree.txt
@@ -8,7 +8,7 @@ git-write-tree - Create a tree object from the current index
 
 SYNOPSIS
 --------
-'git-write-tree' [--missing-ok] [--prefix=<prefix>/]
+'git write-tree' [--missing-ok] [--prefix=<prefix>/]
 
 DESCRIPTION
 -----------
diff --git a/git.html b/git.html
index 219525a84..a86325b32 100644
--- a/git.html
+++ b/git.html
@@ -283,11 +283,11 @@ git(1) Manual Page
 <p>Git is a fast, scalable, distributed revision control system with an
 unusually rich command set that provides both high-level operations
 and full access to internals.</p>
-<p>See this <a href="gittutorial.html">gittutorial(7)</a>[tutorial] to get started, then see
+<p>See <a href="gittutorial.html">gittutorial(7)</a> to get started, then see
 <a href="everyday.html">Everyday Git</a> for a useful minimum set of commands, and
 "man git-commandname" for documentation of each command.  CVS users may
-also want to read <a href="gitcvs-migration.html">gitcvs-migration(7)</a>[CVS migration].  See
-<a href="user-manual.html">Git User's Manual</a> for a more in-depth
+also want to read <a href="gitcvs-migration.html">gitcvs-migration(7)</a>.  See
+the <a href="user-manual.html">Git User's Manual</a> for a more in-depth
 introduction.</p>
 <p>The COMMAND is either a name of a Git command (see below) or an alias
 as defined in the configuration file (see <a href="git-config.html">git-config(1)</a>).</p>
@@ -396,11 +396,12 @@ help &#8230;</em>.</p>
 <p>See the references above to get started using git.  The following is
 probably more detail than necessary for a first-time user.</p>
 <p>The <a href="user-manual.html#git-concepts">git concepts chapter of the
-user-manual</a> and the <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>[Core tutorial] both provide
+user-manual</a> and <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a> both provide
 introductions to the underlying git architecture.</p>
 <p>See also the <a href="howto-index.html">howto</a> documents for some useful
 examples.</p>
-<p>The internals are documented <a href="technical/api-index.html">here</a>.</p>
+<p>The internals are documented in the
+<a href="technical/api-index.html">GIT API documentation</a>.</p>
 </div>
 <h2>GIT COMMANDS</h2>
 <div class="sectionbody">
@@ -1631,15 +1632,14 @@ HEAD
 </div>
 <h2>File/Directory Structure</h2>
 <div class="sectionbody">
-<p>Please see the <a href="gitrepository-layout.html">gitrepository-layout(5)</a>[repository layout]
-document.</p>
-<p>Read <a href="githooks.html">githooks(5)</a>[hooks] for more details about each hook.</p>
+<p>Please see the <a href="gitrepository-layout.html">gitrepository-layout(5)</a> document.</p>
+<p>Read <a href="githooks.html">githooks(5)</a> for more details about each hook.</p>
 <p>Higher level SCMs may provide and manage additional information in the
 <tt>$GIT_DIR</tt>.</p>
 </div>
 <h2>Terminology</h2>
 <div class="sectionbody">
-<p>Please see the <a href="gitglossary.html">gitglossary(7)</a>[glossary] document.</p>
+<p>Please see <a href="gitglossary.html">gitglossary(7)</a>.</p>
 </div>
 <h2>Environment Variables</h2>
 <div class="sectionbody">
@@ -1825,10 +1825,10 @@ parameter, &lt;path&gt;.</p>
 </dt>
 <dd>
 <p>
-        If this environment variable is set then <a href="git-fetch.html">git-fetch(1)</a>
-        and <a href="git-push.html">git-push(1)</a> will use this command instead
+        If this environment variable is set then <tt>git-fetch</tt>
+        and <tt>git-push</tt> will use this command instead
         of <tt>ssh</tt> when they need to connect to a remote system.
-        The <em>GIT_SSH</em> command will be given exactly two arguments:
+        The <em>$GIT_SSH</em> command will be given exactly two arguments:
         the <em>username@host</em> (or just <em>host</em>) from the URL and the
         shell command to execute on that remote system.
 </p>
@@ -1845,8 +1845,8 @@ for further details.</p>
 <dd>
 <p>
         If this environment variable is set to "1", then commands such
-        as git-blame (in incremental mode), git-rev-list, git-log,
-        git-whatchanged, etc., will force a flush of the output stream
+        as <tt>git-blame</tt> (in incremental mode), <tt>git-rev-list</tt>, <tt>git-log</tt>,
+        and <tt>git-whatchanged</tt> will force a flush of the output stream
         after each commit-oriented record have been flushed.   If this
         variable is set to "0", the output of these commands will be done
         using completely buffered I/O.   If this environment variable is
@@ -1879,7 +1879,7 @@ for further details.</p>
 <div class="sectionbody">
 <p>More detail on the following is available from the
 <a href="user-manual.html#git-concepts">git concepts chapter of the
-user-manual</a> and the <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>[Core tutorial].</p>
+user-manual</a> and <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>.</p>
 <p>A git project normally consists of a working directory with a ".git"
 subdirectory at the top level.  The .git directory contains, among other
 things, a compressed object database representing the complete history
@@ -1963,7 +1963,7 @@ contributors on the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 26-Jun-2008 06:33:11 UTC
+Last updated 02-Jul-2008 03:02:08 UTC
 </div>
 </div>
 </body>
diff --git a/git.txt b/git.txt
index 85468a154..bb33c4087 100644
--- a/git.txt
+++ b/git.txt
@@ -20,11 +20,11 @@ Git is a fast, scalable, distributed revision control system with an
 unusually rich command set that provides both high-level operations
 and full access to internals.
 
-See this linkgit:gittutorial[7][tutorial] to get started, then see
+See linkgit:gittutorial[7] to get started, then see
 link:everyday.html[Everyday Git] for a useful minimum set of commands, and
 "man git-commandname" for documentation of each command.  CVS users may
-also want to read linkgit:gitcvs-migration[7][CVS migration].  See
-link:user-manual.html[Git User's Manual] for a more in-depth
+also want to read linkgit:gitcvs-migration[7].  See
+the link:user-manual.html[Git User's Manual] for a more in-depth
 introduction.
 
 The COMMAND is either a name of a Git command (see below) or an alias
@@ -182,13 +182,14 @@ See the references above to get started using git.  The following is
 probably more detail than necessary for a first-time user.
 
 The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial] both provide
+user-manual] and linkgit:gitcore-tutorial[7] both provide
 introductions to the underlying git architecture.
 
 See also the link:howto-index.html[howto] documents for some useful
 examples.
 
-The internals are documented link:technical/api-index.html[here].
+The internals are documented in the
+link:technical/api-index.html[GIT API documentation].
 
 GIT COMMANDS
 ------------
@@ -372,10 +373,9 @@ For a more complete list of ways to spell object names, see
 File/Directory Structure
 ------------------------
 
-Please see the linkgit:gitrepository-layout[5][repository layout]
-document.
+Please see the linkgit:gitrepository-layout[5] document.
 
-Read linkgit:githooks[5][hooks] for more details about each hook.
+Read linkgit:githooks[5] for more details about each hook.
 
 Higher level SCMs may provide and manage additional information in the
 `$GIT_DIR`.
@@ -383,7 +383,7 @@ Higher level SCMs may provide and manage additional information in the
 
 Terminology
 -----------
-Please see the linkgit:gitglossary[7][glossary] document.
+Please see linkgit:gitglossary[7].
 
 
 Environment Variables
@@ -483,10 +483,10 @@ other
 	a pager.
 
 'GIT_SSH'::
-	If this environment variable is set then linkgit:git-fetch[1]
-	and linkgit:git-push[1] will use this command instead
+	If this environment variable is set then `git-fetch`
+	and `git-push` will use this command instead
 	of `ssh` when they need to connect to a remote system.
-	The 'GIT_SSH' command will be given exactly two arguments:
+	The '$GIT_SSH' command will be given exactly two arguments:
 	the 'username@host' (or just 'host') from the URL and the
 	shell command to execute on that remote system.
 +
@@ -500,8 +500,8 @@ for further details.
 
 'GIT_FLUSH'::
 	If this environment variable is set to "1", then commands such
-	as git-blame (in incremental mode), git-rev-list, git-log,
-	git-whatchanged, etc., will force a flush of the output stream
+	as `git-blame` (in incremental mode), `git-rev-list`, `git-log`,
+	and `git-whatchanged` will force a flush of the output stream
 	after each commit-oriented record have been flushed.   If this
 	variable is set to "0", the output of these commands will be done
 	using completely buffered I/O.   If this environment variable is
@@ -527,7 +527,7 @@ Discussion[[Discussion]]
 
 More detail on the following is available from the
 link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial].
+user-manual] and linkgit:gitcore-tutorial[7].
 
 A git project normally consists of a working directory with a ".git"
 subdirectory at the top level.  The .git directory contains, among other
diff --git a/gitattributes.html b/gitattributes.html
index 8268e27d8..49663c8a7 100644
--- a/gitattributes.html
+++ b/gitattributes.html
@@ -358,9 +358,9 @@ operations are attributes-aware.</p>
 <h3>Checking-out and checking-in</h3>
 <p>These attributes affect how the contents stored in the
 repository are copied to the working tree files when commands
-such as <tt>git checkout</tt> and <tt>git merge</tt> run.  They also affect how
+such as <tt>git-checkout</tt> and <tt>git-merge</tt> run.  They also affect how
 git stores the contents you prepare in the working tree in the
-repository upon <tt>git add</tt> and <tt>git commit</tt>.</p>
+repository upon <tt>git-add</tt> and <tt>git-commit</tt>.</p>
 <h4><tt>crlf</tt></h4>
 <p>This attribute controls the line-ending convention.</p>
 <dl>
@@ -428,13 +428,13 @@ few exceptions.  Even though&#8230;</p>
 <ul>
 <li>
 <p>
-"git add" itself does not touch the files in the work tree, the
+<tt>git-add</tt> itself does not touch the files in the work tree, the
   next checkout would, so the safety triggers;
 </p>
 </li>
 <li>
 <p>
-"git apply" to update a text file with a patch does touch the files
+<tt>git-apply</tt> to update a text file with a patch does touch the files
   in the work tree, but the operation is about text files and CRLF
   conversion is about fixing the line ending inconsistencies, so the
   safety does not trigger;
@@ -442,8 +442,8 @@ few exceptions.  Even though&#8230;</p>
 </li>
 <li>
 <p>
-"git diff" itself does not touch the files in the work tree, it is
-  often run to inspect the changes you intend to next "git add".  To
+<tt>git-diff</tt> itself does not touch the files in the work tree, it is
+  often run to inspect the changes you intend to next <tt>git-add</tt>.  To
   catch potential problems early, safety triggers.
 </p>
 </li>
@@ -483,7 +483,7 @@ and applicable).</p>
 <p>In the check-out codepath, the blob content is first converted
 with <tt>crlf</tt>, and then <tt>ident</tt> and fed to <tt>filter</tt>.</p>
 <h3>Generating diff text</h3>
-<p>The attribute <tt>diff</tt> affects if <tt>git diff</tt> generates textual
+<p>The attribute <tt>diff</tt> affects if <tt>git-diff</tt> generates textual
 patch for the path or just says <tt>Binary files differ</tt>.  It also
 can affect what line is shown on the hunk header <tt>@@ -k,l +n,m @@</tt>
 line.</p>
@@ -812,8 +812,8 @@ archive files.</p>
 <h4><tt>export-subst</tt></h4>
 <p>If the attribute <tt>export-subst</tt> is set for a file then git will expand
 several placeholders when adding this file to an archive.  The
-expansion depends on the availability of a commit ID, i.e. if
-<a href="git-archive.html">git-archive(1)</a> has been given a tree instead of a commit or a
+expansion depends on the availability of a commit ID, i.e., if
+<tt>git-archive</tt> has been given a tree instead of a commit or a
 tag then no replacement will be done.  The placeholders are the same
 as those for the option <tt>--pretty=format:</tt> of <a href="git-log.html">git-log(1)</a>,
 except that they need to be wrapped like this: <tt>$Format:PLACEHOLDERS$</tt>
@@ -826,7 +826,7 @@ commit hash.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:37 UTC
+Last updated 02-Jul-2008 03:02:09 UTC
 </div>
 </div>
 </body>
diff --git a/gitattributes.txt b/gitattributes.txt
index 6e67990f6..124170a96 100644
--- a/gitattributes.txt
+++ b/gitattributes.txt
@@ -87,9 +87,9 @@ Checking-out and checking-in
 
 These attributes affect how the contents stored in the
 repository are copied to the working tree files when commands
-such as `git checkout` and `git merge` run.  They also affect how
+such as `git-checkout` and `git-merge` run.  They also affect how
 git stores the contents you prepare in the working tree in the
-repository upon `git add` and `git commit`.
+repository upon `git-add` and `git-commit`.
 
 `crlf`
 ^^^^^^
@@ -148,16 +148,16 @@ an irreversible conversion.  The safety triggers to prevent such
 a conversion done to the files in the work tree, but there are a
 few exceptions.  Even though...
 
-- "git add" itself does not touch the files in the work tree, the
+- `git-add` itself does not touch the files in the work tree, the
   next checkout would, so the safety triggers;
 
-- "git apply" to update a text file with a patch does touch the files
+- `git-apply` to update a text file with a patch does touch the files
   in the work tree, but the operation is about text files and CRLF
   conversion is about fixing the line ending inconsistencies, so the
   safety does not trigger;
 
-- "git diff" itself does not touch the files in the work tree, it is
-  often run to inspect the changes you intend to next "git add".  To
+- `git-diff` itself does not touch the files in the work tree, it is
+  often run to inspect the changes you intend to next `git-add`.  To
   catch potential problems early, safety triggers.
 
 
@@ -214,7 +214,7 @@ with `crlf`, and then `ident` and fed to `filter`.
 Generating diff text
 ~~~~~~~~~~~~~~~~~~~~
 
-The attribute `diff` affects if `git diff` generates textual
+The attribute `diff` affects if `git-diff` generates textual
 patch for the path or just says `Binary files differ`.  It also
 can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
 line.
@@ -513,8 +513,8 @@ archive files.
 
 If the attribute `export-subst` is set for a file then git will expand
 several placeholders when adding this file to an archive.  The
-expansion depends on the availability of a commit ID, i.e. if
-linkgit:git-archive[1] has been given a tree instead of a commit or a
+expansion depends on the availability of a commit ID, i.e., if
+`git-archive` has been given a tree instead of a commit or a
 tag then no replacement will be done.  The placeholders are the same
 as those for the option `--pretty=format:` of linkgit:git-log[1],
 except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
diff --git a/gitcli.html b/gitcli.html
index 7eca88442..1ec6b6faa 100644
--- a/gitcli.html
+++ b/gitcli.html
@@ -415,9 +415,50 @@ $ git describe --abbrev=10 HEAD  # correct
 $ git describe --abbrev 10 HEAD  # NOT WHAT YOU MEANT</tt></pre>
 </div></div>
 </div>
+<h2>NOTES ON FREQUENTLY CONFUSED OPTIONS</h2>
+<div class="sectionbody">
+<p>Many commands that can work on files in the working tree
+and/or in the index can take <tt>--cached</tt> and/or <tt>--index</tt>
+options.  Sometimes people incorrectly think that, because
+the index was originally called cache, these two are
+synonyms.  They are <strong>not</strong> &#8212; these two options mean very
+different things.</p>
+<ul>
+<li>
+<p>
+The <tt>--cached</tt> option is used to ask a command that
+   usually works on files in the working tree to <strong>only</strong> work
+   with the index.  For example, <tt>git grep</tt>, when used
+   without a commit to specify from which commit to look for
+   strings in, usually works on files in the working tree,
+   but with the <tt>--cached</tt> option, it looks for strings in
+   the index.
+</p>
+</li>
+<li>
+<p>
+The <tt>--index</tt> option is used to ask a command that
+   usually works on files in the working tree to <strong>also</strong>
+   affect the index.  For example, <tt>git stash apply</tt> usually
+   merges changes recorded in a stash to the working tree,
+   but with the <tt>--index</tt> option, it also merges changes to
+   the index as well.
+</p>
+</li>
+</ul>
+<p><tt>git apply</tt> command can be used with <tt>--cached</tt> and
+<tt>--index</tt> (but not at the same time).  Usually the command
+only affects the files in the working tree, but with
+<tt>--index</tt>, it patches both the files and their index
+entries, and with <tt>--cached</tt>, it modifies only the index
+entries.</p>
+<p>See also http://marc.info/?l=git&amp;m=116563135620359 and
+http://marc.info/?l=git&amp;m=119150393620273 for further
+information.</p>
+</div>
 <h2>Documentation</h2>
 <div class="sectionbody">
-<p>Documentation by Pierre Habouzit.</p>
+<p>Documentation by Pierre Habouzit and the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <h2>GIT</h2>
 <div class="sectionbody">
@@ -425,7 +466,7 @@ $ git describe --abbrev 10 HEAD  # NOT WHAT YOU MEANT</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 28-Jun-2008 10:07:02 UTC
+Last updated 02-Jul-2008 03:02:11 UTC
 </div>
 </div>
 </body>
diff --git a/gitcli.txt b/gitcli.txt
index 231604986..29e5929db 100644
--- a/gitcli.txt
+++ b/gitcli.txt
@@ -133,9 +133,45 @@ $ git describe --abbrev 10 HEAD  # NOT WHAT YOU MEANT
 ----------------------------
 
 
+NOTES ON FREQUENTLY CONFUSED OPTIONS
+------------------------------------
+
+Many commands that can work on files in the working tree
+and/or in the index can take `--cached` and/or `--index`
+options.  Sometimes people incorrectly think that, because
+the index was originally called cache, these two are
+synonyms.  They are *not* -- these two options mean very
+different things.
+
+ * The `--cached` option is used to ask a command that
+   usually works on files in the working tree to *only* work
+   with the index.  For example, `git grep`, when used
+   without a commit to specify from which commit to look for
+   strings in, usually works on files in the working tree,
+   but with the `--cached` option, it looks for strings in
+   the index.
+
+ * The `--index` option is used to ask a command that
+   usually works on files in the working tree to *also*
+   affect the index.  For example, `git stash apply` usually
+   merges changes recorded in a stash to the working tree,
+   but with the `--index` option, it also merges changes to
+   the index as well.
+
+`git apply` command can be used with `--cached` and
+`--index` (but not at the same time).  Usually the command
+only affects the files in the working tree, but with
+`--index`, it patches both the files and their index
+entries, and with `--cached`, it modifies only the index
+entries.
+
+See also http://marc.info/?l=git&m=116563135620359 and
+http://marc.info/?l=git&m=119150393620273 for further
+information.
+
 Documentation
 -------------
-Documentation by Pierre Habouzit.
+Documentation by Pierre Habouzit and the git-list <git@vger.kernel.org>.
 
 GIT
 ---
diff --git a/gitcore-tutorial.html b/gitcore-tutorial.html
index 2f30e0205..4d31bd94a 100644
--- a/gitcore-tutorial.html
+++ b/gitcore-tutorial.html
@@ -279,8 +279,8 @@ gitcore-tutorial(7) Manual Page
 <p>This tutorial explains how to use the "core" git programs to set up and
 work with a git repository.</p>
 <p>If you just need to use git as a revision control system you may prefer
-to start with <a href="gittutorial.html">gittutorial(7)</a>[a tutorial introduction to git] or
-<a href="user-manual.html">the git user manual</a>.</p>
+to start with "A Tutorial Introduction to GIT" (<a href="gittutorial.html">gittutorial(7)</a>) or
+<a href="user-manual.html">the GIT User Manual</a>.</p>
 <p>However, an understanding of these low-level tools can be helpful if
 you want to understand git's internals.</p>
 <p>The core git is often called "plumbing", with the prettier user
@@ -312,7 +312,7 @@ subdirectory, and initialize the git infrastructure with <tt>git-init</tt>:</p>
 <div class="content">
 <pre><tt>$ mkdir git-tutorial
 $ cd git-tutorial
-$ git-init</tt></pre>
+$ git init</tt></pre>
 </div></div>
 <p>to which git will reply</p>
 <div class="listingblock">
@@ -384,8 +384,7 @@ populating your tree.</td>
 <td class="icon">
 <div class="title">Note</div>
 </td>
-<td class="content">An advanced user may want to take a look at the
-<a href="gitrepository-layout.html">gitrepository-layout(5)</a>[repository layout] document
+<td class="content">An advanced user may want to take a look at <a href="gitrepository-layout.html">gitrepository-layout(5)</a>
 after finishing this tutorial.</td>
 </tr></table>
 </div>
@@ -429,7 +428,7 @@ adding a new entry with the <tt>--add</tt> flag (or removing an entry with the
 <p>So to populate the index with the two files you just created, you can do</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-update-index --add hello example</tt></pre>
+<pre><tt>$ git update-index --add hello example</tt></pre>
 </div></div>
 <p>and you have now told git to track those two files.</p>
 <p>In fact, as you did that, if you now look into your object directory,
@@ -451,14 +450,14 @@ database. If you did exactly the steps above, you should now be able to do</p>
 you'll have to use the object name, not the filename of the object:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238</tt></pre>
+<pre><tt>$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238</tt></pre>
 </div></div>
 <p>where the <tt>-t</tt> tells <tt>git-cat-file</tt> to tell you what the "type" of the
 object is. git will tell you that you have a "blob" object (i.e., just a
 regular file), and you can see the contents with</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-cat-file "blob" 557db03</tt></pre>
+<pre><tt>$ git cat-file "blob" 557db03</tt></pre>
 </div></div>
 <p>which will print out "Hello World". The object <tt>557db03</tt> is nothing
 more than the contents of your file <tt>hello</tt>.</p>
@@ -508,17 +507,17 @@ git what has changed in the tree compared to your old index, using the
 <tt>git-diff-files</tt> command:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-diff-files</tt></pre>
+<pre><tt>$ git diff-files</tt></pre>
 </div></div>
 <p>Oops. That wasn't very readable. It just spit out its own internal
 version of a <tt>diff</tt>, but that internal version really just tells you
 that it has noticed that "hello" has been modified, and that the old object
 contents it had have been replaced with something else.</p>
-<p>To make it readable, we can tell git-diff-files to output the
+<p>To make it readable, we can tell <tt>git-diff-files</tt> to output the
 differences as a patch, using the <tt>-p</tt> flag:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-diff-files -p
+<pre><tt>$ git diff-files -p
 diff --git a/hello b/hello
 index 557db03..263414f 100644
 --- a/hello
@@ -531,7 +530,7 @@ index 557db03..263414f 100644
 <p>In other words, <tt>git-diff-files</tt> always shows us the difference between
 what is recorded in the index, and what is currently in the working
 tree. That's very useful.</p>
-<p>A common shorthand for <tt>git-diff-files -p</tt> is to just write <tt>git
+<p>A common shorthand for <tt>git diff-files -p</tt> is to just write <tt>git
 diff</tt>, which will do the same thing.</p>
 <div class="listingblock">
 <div class="content">
@@ -553,14 +552,14 @@ that in two phases: creating a <em>tree</em> object, and committing that <em>tre
 object as a <em>commit</em> object together with an explanation of what the
 tree was all about, along with information of how we came to that state.</p>
 <p>Creating a tree object is trivial, and is done with <tt>git-write-tree</tt>.
-There are no options or other input: git-write-tree will take the
+There are no options or other input: <tt>git write-tree</tt> will take the
 current index state, and write an object that describes that whole
 index. In other words, we're now tying together all the different
 filenames with their contents (and their permissions), and we're
 creating the equivalent of a git "directory" object:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-write-tree</tt></pre>
+<pre><tt>$ git write-tree</tt></pre>
 </div></div>
 <p>and this will just output the name of the resulting tree, in this case
 (if you have done exactly as I've described) it should be</p>
@@ -569,9 +568,9 @@ creating the equivalent of a git "directory" object:</p>
 <pre><tt>8988da15d077d4829fc51d8544c097def6644dbb</tt></pre>
 </div></div>
 <p>which is another incomprehensible object name. Again, if you want to,
-you can use <tt>git-cat-file -t 8988d...</tt> to see that this time the object
+you can use <tt>git cat-file -t 8988d...</tt> to see that this time the object
 is not a "blob" object, but a "tree" object (you can also use
-<tt>git-cat-file</tt> to actually output the raw object contents, but you'll see
+<tt>git cat-file</tt> to actually output the raw object contents, but you'll see
 mainly a binary mess, so that's less interesting).</p>
 <p>However &#8212; normally you'd never use <tt>git-write-tree</tt> on its own, because
 normally you always commit a tree into a commit object using the
@@ -591,9 +590,9 @@ that's exactly what <tt>git-commit-tree</tt> spits out, we can do this
 all with a sequence of simple shell commands:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ tree=$(git-write-tree)
-$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
-$ git-update-ref HEAD $commit</tt></pre>
+<pre><tt>$ tree=$(git write-tree)
+$ commit=$(echo 'Initial commit' | git commit-tree $tree)
+$ git update-ref HEAD $commit</tt></pre>
 </div></div>
 <p>In this case this creates a totally new commit that is not related to
 anything else. Normally you do this only <strong>once</strong> for a project ever, and
@@ -614,7 +613,7 @@ fact the <strong>original</strong> contents of the file <tt>hello</tt>, not the
 that on purpose, to show the difference between the index state, and the
 state in the working tree, and how they don't have to match, even
 when we commit things.</p>
-<p>As before, if we do <tt>git-diff-files -p</tt> in our git-tutorial project,
+<p>As before, if we do <tt>git diff-files -p</tt> in our git-tutorial project,
 we'll still see the same difference we saw last time: the index file
 hasn't changed by the act of committing anything. However, now that we
 have committed something, we can also learn to use a new command:
@@ -628,7 +627,7 @@ didn't have anything to diff against.</p>
 <p>But now we can do</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-diff-index -p HEAD</tt></pre>
+<pre><tt>$ git diff-index -p HEAD</tt></pre>
 </div></div>
 <p>(where <tt>-p</tt> has the same meaning as it did in <tt>git-diff-files</tt>), and it
 will show us the same difference, but for a totally different reason.
@@ -646,7 +645,7 @@ it with</p>
 working tree, but when given the <tt>--cached</tt> flag, it is told to
 instead compare against just the index cache contents, and ignore the
 current working tree state entirely. Since we just wrote the index
-file to HEAD, doing <tt>git-diff-index --cached -p HEAD</tt> should thus return
+file to HEAD, doing <tt>git diff-index --cached -p HEAD</tt> should thus return
 an empty set of differences, and that's exactly what it does.</p>
 <div class="admonitionblock">
 <table><tr>
@@ -677,13 +676,13 @@ work through the index file, so the first thing we need to do is to
 update the index cache:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-update-index hello</tt></pre>
+<pre><tt>$ git update-index hello</tt></pre>
 </div></div>
 <p>(note how we didn't need the <tt>--add</tt> flag this time, since git knew
 about the file already).</p>
 <p>Note what happens to the different <tt>git-diff-*</tt> versions here. After
-we've updated <tt>hello</tt> in the index, <tt>git-diff-files -p</tt> now shows no
-differences, but <tt>git-diff-index -p HEAD</tt> still *does* show that the
+we've updated <tt>hello</tt> in the index, <tt>git diff-files -p</tt> now shows no
+differences, but <tt>git diff-index -p HEAD</tt> still *does* show that the
 current state is different from the state we committed. In fact, now
 <tt>git-diff-index</tt> shows the same difference whether we use the <tt>--cached</tt>
 flag or not, since now the index is coherent with the working tree.</p>
@@ -723,7 +722,7 @@ of that commit itself, and show the difference directly. Thus, to get
 the same diff that we've already seen several times, we can now do</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-diff-tree -p HEAD</tt></pre>
+<pre><tt>$ git diff-tree -p HEAD</tt></pre>
 </div></div>
 <p>(again, <tt>-p</tt> means to show the difference as a human-readable patch),
 and it will show what the last commit (in <tt>HEAD</tt>) actually changed.</p>
@@ -790,7 +789,7 @@ with the associated patches use the more complex (and much more
 powerful)</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-whatchanged -p</tt></pre>
+<pre><tt>$ git whatchanged -p</tt></pre>
 </div></div>
 <p>and you will see exactly what has changed in the repository over its
 short history.</p>
@@ -907,7 +906,7 @@ information for the files involved) will likely need to be refreshed.
 So after you do a <tt>cp -a</tt> to create a new copy, you'll want to do</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-update-index --refresh</tt></pre>
+<pre><tt>$ git update-index --refresh</tt></pre>
 </div></div>
 <p>in the new repository to make sure that the index file is up-to-date.</p>
 </li>
@@ -922,14 +921,14 @@ known state (you don't know <strong>what</strong> they've done and not yet check
 so usually you'll precede the <tt>git-update-index</tt> with a</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-read-tree --reset HEAD
-$ git-update-index --refresh</tt></pre>
+<pre><tt>$ git read-tree --reset HEAD
+$ git update-index --refresh</tt></pre>
 </div></div>
 <p>which will force a total index re-build from the tree pointed to by <tt>HEAD</tt>.
 It resets the index contents to <tt>HEAD</tt>, and then the <tt>git-update-index</tt>
 makes sure to match up all index entries with the checked-out files.
 If the original repository had uncommitted changes in its
-working tree, <tt>git-update-index --refresh</tt> notices them and
+working tree, <tt>git update-index --refresh</tt> notices them and
 tells you they need to be updated.</p>
 <p>The above can also be written as simply</p>
 <div class="listingblock">
@@ -940,7 +939,7 @@ tells you they need to be updated.</p>
 with the <tt>git xyz</tt> interfaces.  You can learn things by just looking
 at what the various git scripts do.  For example, <tt>git reset</tt> used to be
 the above two lines implemented in <tt>git-reset</tt>, but some things like
-<tt>git status</tt> and <tt>git commit</tt> are slightly more complex scripts around
+<tt>git-status</tt> and <tt>git-commit</tt> are slightly more complex scripts around
 the basic git commands.</p>
 <p>Many (most?) public remote repositories will not contain any of
 the checked out files or even an index file, and will <strong>only</strong> contain the
@@ -960,7 +959,7 @@ $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git</tt></pre>
 <p>followed by</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-read-tree HEAD</tt></pre>
+<pre><tt>$ git read-tree HEAD</tt></pre>
 </div></div>
 <p>to populate the index. However, now you have populated the index, and
 you have all the git internal files, but you will notice that you don't
@@ -968,13 +967,13 @@ actually have any of the working tree files to work on. To get
 those, you'd check them out with</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-checkout-index -u -a</tt></pre>
+<pre><tt>$ git checkout-index -u -a</tt></pre>
 </div></div>
 <p>where the <tt>-u</tt> flag means that you want the checkout to keep the index
 up-to-date (so that you don't have to refresh it afterward), and the
 <tt>-a</tt> flag means "check out all files" (if you have a stale copy or an
 older version of a checked out tree you may also need to add the <tt>-f</tt>
-flag first, to tell git-checkout-index to <strong>force</strong> overwriting of any old
+flag first, to tell <tt>git-checkout-index</tt> to <strong>force</strong> overwriting of any old
 files).</p>
 <p>Again, this can all be simplified with</p>
 <div class="listingblock">
@@ -1071,7 +1070,7 @@ $ echo "Work, work, work" &gt;&gt;hello
 $ git commit -m "Some work." -i hello</tt></pre>
 </div></div>
 <p>Here, we just added another line to <tt>hello</tt>, and we used a shorthand for
-doing both <tt>git-update-index hello</tt> and <tt>git commit</tt> by just giving the
+doing both <tt>git update-index hello</tt> and <tt>git commit</tt> by just giving the
 filename directly to <tt>git commit</tt>, with an <tt>-i</tt> flag (it tells
 git to <em>include</em> that file in addition to what you have done to
 the index file so far when making the commit).  The <tt>-m</tt> flag is to give the
@@ -1145,7 +1144,7 @@ Work, work, work</tt></pre>
 </div></div>
 <p>which will very loudly warn you that you're now committing a merge
 (which is correct, so never mind), and you can write a small merge
-message about your adventures in git-merge-land.</p>
+message about your adventures in <tt>git-merge</tt>-land.</p>
 <p>After you're done, start up <tt>gitk --all</tt> to see graphically what the
 history looks like. Notice that <tt>mybranch</tt> still exists, and you can
 switch to it, and continue to work with it if you want to. The
@@ -1156,7 +1155,7 @@ have to do _that_ merge again.</p>
 environment, is <tt>git show-branch</tt>.</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-show-branch --topo-order --more=1 master mybranch
+<pre><tt>$ git show-branch --topo-order --more=1 master mybranch
 * [master] Merge work in mybranch
  ! [mybranch] Some work.
 --
@@ -1180,17 +1179,17 @@ commits from the master branch.  The string inside brackets
 before the commit log message is a short name you can use to
 name the commit.  In the above example, <em>master</em> and <em>mybranch</em>
 are branch heads.  <em>master^</em> is the first parent of <em>master</em>
-branch head.  Please see <em>git-rev-parse</em> documentation if you
+branch head.  Please see <a href="git-rev-parse.html">git-rev-parse(1)</a> if you want to
 see more complex cases.</p>
 <div class="admonitionblock">
 <table><tr>
 <td class="icon">
 <div class="title">Note</div>
 </td>
-<td class="content">Without the <em>--more=1</em> option, <em>git-show-branch</em> would not output the
+<td class="content">Without the <em>--more=1</em> option, <tt>git-show-branch</tt> would not output the
 <em>[master^]</em> commit, as <em>[mybranch]</em> commit is a common ancestor of
-both <em>master</em> and <em>mybranch</em> tips.  Please see <em>git-show-branch</em>
-documentation for details.</td>
+both <em>master</em> and <em>mybranch</em> tips.  Please see <a href="git-show-branch.html">git-show-branch(1)</a>
+for details.</td>
 </tr></table>
 </div>
 <div class="admonitionblock">
@@ -1199,7 +1198,7 @@ documentation for details.</td>
 <div class="title">Note</div>
 </td>
 <td class="content">If there were more commits on the <em>master</em> branch after the merge, the
-merge commit itself would not be shown by <em>git-show-branch</em> by
+merge commit itself would not be shown by <tt>git-show-branch</tt> by
 default.  You would need to provide <em>--sparse</em> option to make the
 merge commit visible in this case.</td>
 </tr></table>
@@ -1207,7 +1206,7 @@ merge commit visible in this case.</td>
 <p>Now, let's pretend you are the one who did all the work in
 <tt>mybranch</tt>, and the fruit of your hard work has finally been merged
 to the <tt>master</tt> branch. Let's go back to <tt>mybranch</tt>, and run
-<tt>git merge</tt> to get the "upstream changes" back to your branch.</p>
+<tt>git-merge</tt> to get the "upstream changes" back to your branch.</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git checkout mybranch
@@ -1446,7 +1445,7 @@ algorithm.  First, it finds the common ancestor between them.
 The command it uses is <tt>git-merge-base</tt>:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ mb=$(git-merge-base HEAD mybranch)</tt></pre>
+<pre><tt>$ mb=$(git merge-base HEAD mybranch)</tt></pre>
 </div></div>
 <p>The command writes the commit object name of the common ancestor
 to the standard output, so we captured its output to a variable,
@@ -1455,14 +1454,14 @@ ancestor commit is the "New day." commit in this case.  You can
 tell it by:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-name-rev $mb
+<pre><tt>$ git name-rev $mb
 my-first-tag</tt></pre>
 </div></div>
 <p>After finding out a common ancestor commit, the second step is
 this:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-read-tree -m -u $mb HEAD mybranch</tt></pre>
+<pre><tt>$ git read-tree -m -u $mb HEAD mybranch</tt></pre>
 </div></div>
 <p>This is the same <tt>git-read-tree</tt> command we have already seen,
 but it takes three trees, unlike previous examples.  This reads
@@ -1479,7 +1478,7 @@ trees are left in non-zero stages.  At this point, you can
 inspect the index file with this command:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-ls-files --stage
+<pre><tt>$ git ls-files --stage
 100644 7f8b141b65fdcee47321e399a2598a235a032422 0       example
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1       hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2       hello
@@ -1494,7 +1493,7 @@ stages.</p>
 <p>To look at only non-zero stages, use <tt>--unmerged</tt> flag:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-ls-files --unmerged
+<pre><tt>$ git ls-files --unmerged
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1       hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2       hello
 100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello</tt></pre>
@@ -1505,7 +1504,7 @@ file, using 3-way merge.  This is done by giving
 <tt>git-merge-index</tt> command:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-merge-index git-merge-one-file hello
+<pre><tt>$ git merge-index git-merge-one-file hello
 Auto-merging hello.
 merge: warning: conflicts during merge
 ERROR: Merge conflict in hello.
@@ -1522,16 +1521,16 @@ the working tree..  This can be seen if you run <tt>ls-files
 --stage</tt> again at this point:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-ls-files --stage
+<pre><tt>$ git ls-files --stage
 100644 7f8b141b65fdcee47321e399a2598a235a032422 0       example
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1       hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2       hello
 100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello</tt></pre>
 </div></div>
 <p>This is the state of the index file and the working file after
-<tt>git merge</tt> returns control back to you, leaving the conflicting
+<tt>git-merge</tt> returns control back to you, leaving the conflicting
 merge for you to resolve.  Notice that the path <tt>hello</tt> is still
-unmerged, and what you see with <tt>git diff</tt> at this point is
+unmerged, and what you see with <tt>git-diff</tt> at this point is
 differences since stage 2 (i.e. your version).</p>
 </div>
 <h2>Publishing your work</h2>
@@ -1571,7 +1570,7 @@ done only once.</p>
 <td class="icon">
 <div class="title">Note</div>
 </td>
-<td class="content"><tt>git push</tt> uses a pair of programs,
+<td class="content"><tt>git-push</tt> uses a pair of programs,
 <tt>git-send-pack</tt> on your local machine, and <tt>git-receive-pack</tt>
 on the remote machine. The communication between the two over
 the network internally uses an SSH connection.</td>
@@ -1591,7 +1590,7 @@ an empty directory:</p>
 <tt>.git</tt>, we do things slightly differently:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ GIT_DIR=my-git.git git-init</tt></pre>
+<pre><tt>$ GIT_DIR=my-git.git git init</tt></pre>
 </div></div>
 <p>Make sure this directory is available for others you want your
 changes to be pulled by via the transport of your choice. Also
@@ -1617,7 +1616,7 @@ your login shell is <tt>bash</tt>, only <tt>.bashrc</tt> is read and not
 <td class="content">If you plan to publish this repository to be accessed over http,
 you should do <tt>chmod +x my-git.git/hooks/post-update</tt> at this
 point.  This makes sure that every time you push into this
-repository, <tt>git-update-server-info</tt> is run.</td>
+repository, <tt>git update-server-info</tt> is run.</td>
 </tr></table>
 </div>
 <p>Your "public repository" is now ready to accept your changes.
@@ -1750,9 +1749,9 @@ Push into the public repository from your primary
 </li>
 <li>
 <p>
-<tt>git repack</tt> the public repository. This establishes a big
+<tt>git-repack</tt> the public repository. This establishes a big
    pack that contains the initial set of objects as the
-   baseline, and possibly <tt>git prune</tt> if the transport
+   baseline, and possibly <tt>git-prune</tt> if the transport
    used for pulling from your repository supports packed
    repositories.
 </p>
@@ -1774,7 +1773,7 @@ Push your changes to the public repository, and announce it
 </li>
 <li>
 <p>
-Every once in a while, "git repack" the public repository.
+Every once in a while, "git-repack" the public repository.
    Go back to step 5. and continue working.
 </p>
 </li>
@@ -1784,7 +1783,7 @@ on that project and has an own "public repository" goes like this:</p>
 <ol>
 <li>
 <p>
-Prepare your work repository, by <tt>git clone</tt> the public
+Prepare your work repository, by <tt>git-clone</tt> the public
    repository of the "project lead". The URL used for the
    initial cloning is stored in the remote.origin.url
    configuration variable.
@@ -1808,7 +1807,7 @@ Copy over the packed files from "project lead" public
 <li>
 <p>
 Push into the public repository from your primary
-   repository. Run <tt>git repack</tt>, and possibly <tt>git prune</tt> if the
+   repository. Run <tt>git-repack</tt>, and possibly <tt>git-prune</tt> if the
    transport used for pulling from your repository supports
    packed repositories.
 </p>
@@ -1833,7 +1832,7 @@ Push your changes to your public repository, and ask your
 </li>
 <li>
 <p>
-Every once in a while, <tt>git repack</tt> the public repository.
+Every once in a while, <tt>git-repack</tt> the public repository.
    Go back to step 5. and continue working.
 </p>
 </li>
@@ -1844,7 +1843,7 @@ like this:</p>
 <ol>
 <li>
 <p>
-Prepare your work repository, by <tt>git clone</tt> the public
+Prepare your work repository, by <tt>git-clone</tt> the public
    repository of the "project lead" (or a "subsystem
    maintainer", if you work on a subsystem). The URL used for
    the initial cloning is stored in the remote.origin.url
@@ -1886,7 +1885,7 @@ Use <tt>git format-patch origin</tt> to prepare patches for e-mail
 suggested in the previous section may be new to you. You do not
 have to worry. git supports "shared public repository" style of
 cooperation you are probably more familiar with as well.</p>
-<p>See <a href="gitcvs-migration.html">gitcvs-migration(7)</a>[git for CVS users] for the details.</p>
+<p>See <a href="gitcvs-migration.html">gitcvs-migration(7)</a> for the details.</p>
 </div>
 <h2>Bundling your work together</h2>
 <div class="sectionbody">
@@ -1990,7 +1989,7 @@ to follow, not easier.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:31 UTC
+Last updated 02-Jul-2008 03:02:12 UTC
 </div>
 </div>
 </body>
diff --git a/gitcore-tutorial.txt b/gitcore-tutorial.txt
index cb4ec4044..7d721c5b0 100644
--- a/gitcore-tutorial.txt
+++ b/gitcore-tutorial.txt
@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git programs to set up and
 work with a git repository.
 
 If you just need to use git as a revision control system you may prefer
-to start with linkgit:gittutorial[7][a tutorial introduction to git] or
-link:user-manual.html[the git user manual].
+to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
+link:user-manual.html[the GIT User Manual].
 
 However, an understanding of these low-level tools can be helpful if
 you want to understand git's internals.
@@ -49,7 +49,7 @@ subdirectory, and initialize the git infrastructure with `git-init`:
 ------------------------------------------------
 $ mkdir git-tutorial
 $ cd git-tutorial
-$ git-init
+$ git init
 ------------------------------------------------
 
 to which git will reply
@@ -108,8 +108,7 @@ references in these `refs` subdirectories when you actually start
 populating your tree.
 
 [NOTE]
-An advanced user may want to take a look at the
-linkgit:gitrepository-layout[5][repository layout] document
+An advanced user may want to take a look at linkgit:gitrepository-layout[5]
 after finishing this tutorial.
 
 You have now created your first git repository. Of course, since it's
@@ -150,7 +149,7 @@ adding a new entry with the `\--add` flag (or removing an entry with the
 So to populate the index with the two files you just created, you can do
 
 ------------------------------------------------
-$ git-update-index --add hello example
+$ git update-index --add hello example
 ------------------------------------------------
 
 and you have now told git to track those two files.
@@ -178,7 +177,7 @@ If you want to, you can use `git-cat-file` to look at those objects, but
 you'll have to use the object name, not the filename of the object:
 
 ----------------
-$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
 ----------------
 
 where the `-t` tells `git-cat-file` to tell you what the "type" of the
@@ -186,7 +185,7 @@ object is. git will tell you that you have a "blob" object (i.e., just a
 regular file), and you can see the contents with
 
 ----------------
-$ git-cat-file "blob" 557db03
+$ git cat-file "blob" 557db03
 ----------------
 
 which will print out "Hello World". The object `557db03` is nothing
@@ -232,7 +231,7 @@ git what has changed in the tree compared to your old index, using the
 `git-diff-files` command:
 
 ------------
-$ git-diff-files
+$ git diff-files
 ------------
 
 Oops. That wasn't very readable. It just spit out its own internal
@@ -240,11 +239,11 @@ version of a `diff`, but that internal version really just tells you
 that it has noticed that "hello" has been modified, and that the old object
 contents it had have been replaced with something else.
 
-To make it readable, we can tell git-diff-files to output the
+To make it readable, we can tell `git-diff-files` to output the
 differences as a patch, using the `-p` flag:
 
 ------------
-$ git-diff-files -p
+$ git diff-files -p
 diff --git a/hello b/hello
 index 557db03..263414f 100644
 --- a/hello
@@ -260,7 +259,7 @@ In other words, `git-diff-files` always shows us the difference between
 what is recorded in the index, and what is currently in the working
 tree. That's very useful.
 
-A common shorthand for `git-diff-files -p` is to just write `git
+A common shorthand for `git diff-files -p` is to just write `git
 diff`, which will do the same thing.
 
 ------------
@@ -285,14 +284,14 @@ object as a 'commit' object together with an explanation of what the
 tree was all about, along with information of how we came to that state.
 
 Creating a tree object is trivial, and is done with `git-write-tree`.
-There are no options or other input: git-write-tree will take the
+There are no options or other input: `git write-tree` will take the
 current index state, and write an object that describes that whole
 index. In other words, we're now tying together all the different
 filenames with their contents (and their permissions), and we're
 creating the equivalent of a git "directory" object:
 
 ------------------------------------------------
-$ git-write-tree
+$ git write-tree
 ------------------------------------------------
 
 and this will just output the name of the resulting tree, in this case
@@ -303,9 +302,9 @@ and this will just output the name of the resulting tree, in this case
 ----------------
 
 which is another incomprehensible object name. Again, if you want to,
-you can use `git-cat-file -t 8988d\...` to see that this time the object
+you can use `git cat-file -t 8988d\...` to see that this time the object
 is not a "blob" object, but a "tree" object (you can also use
-`git-cat-file` to actually output the raw object contents, but you'll see
+`git cat-file` to actually output the raw object contents, but you'll see
 mainly a binary mess, so that's less interesting).
 
 However -- normally you'd never use `git-write-tree` on its own, because
@@ -328,9 +327,9 @@ that's exactly what `git-commit-tree` spits out, we can do this
 all with a sequence of simple shell commands:
 
 ------------------------------------------------
-$ tree=$(git-write-tree)
-$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
-$ git-update-ref HEAD $commit
+$ tree=$(git write-tree)
+$ commit=$(echo 'Initial commit' | git commit-tree $tree)
+$ git update-ref HEAD $commit
 ------------------------------------------------
 
 In this case this creates a totally new commit that is not related to
@@ -357,7 +356,7 @@ that on purpose, to show the difference between the index state, and the
 state in the working tree, and how they don't have to match, even
 when we commit things.
 
-As before, if we do `git-diff-files -p` in our git-tutorial project,
+As before, if we do `git diff-files -p` in our git-tutorial project,
 we'll still see the same difference we saw last time: the index file
 hasn't changed by the act of committing anything. However, now that we
 have committed something, we can also learn to use a new command:
@@ -373,7 +372,7 @@ didn't have anything to diff against.
 But now we can do
 
 ----------------
-$ git-diff-index -p HEAD
+$ git diff-index -p HEAD
 ----------------
 
 (where `-p` has the same meaning as it did in `git-diff-files`), and it
@@ -395,7 +394,7 @@ In other words, `git-diff-index` normally compares a tree against the
 working tree, but when given the `\--cached` flag, it is told to
 instead compare against just the index cache contents, and ignore the
 current working tree state entirely. Since we just wrote the index
-file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
+file to HEAD, doing `git diff-index \--cached -p HEAD` should thus return
 an empty set of differences, and that's exactly what it does.
 
 [NOTE]
@@ -423,15 +422,15 @@ work through the index file, so the first thing we need to do is to
 update the index cache:
 
 ------------------------------------------------
-$ git-update-index hello
+$ git update-index hello
 ------------------------------------------------
 
 (note how we didn't need the `\--add` flag this time, since git knew
 about the file already).
 
 Note what happens to the different `git-diff-\*` versions here. After
-we've updated `hello` in the index, `git-diff-files -p` now shows no
-differences, but `git-diff-index -p HEAD` still *does* show that the
+we've updated `hello` in the index, `git diff-files -p` now shows no
+differences, but `git diff-index -p HEAD` still *does* show that the
 current state is different from the state we committed. In fact, now
 `git-diff-index` shows the same difference whether we use the `--cached`
 flag or not, since now the index is coherent with the working tree.
@@ -478,7 +477,7 @@ of that commit itself, and show the difference directly. Thus, to get
 the same diff that we've already seen several times, we can now do
 
 ----------------
-$ git-diff-tree -p HEAD
+$ git diff-tree -p HEAD
 ----------------
 
 (again, `-p` means to show the difference as a human-readable patch),
@@ -543,7 +542,7 @@ with the associated patches use the more complex (and much more
 powerful)
 
 ----------------
-$ git-whatchanged -p
+$ git whatchanged -p
 ----------------
 
 and you will see exactly what has changed in the repository over its
@@ -654,7 +653,7 @@ information for the files involved) will likely need to be refreshed.
 So after you do a `cp -a` to create a new copy, you'll want to do
 +
 ----------------
-$ git-update-index --refresh
+$ git update-index --refresh
 ----------------
 +
 in the new repository to make sure that the index file is up-to-date.
@@ -670,15 +669,15 @@ known state (you don't know *what* they've done and not yet checked in),
 so usually you'll precede the `git-update-index` with a
 
 ----------------
-$ git-read-tree --reset HEAD
-$ git-update-index --refresh
+$ git read-tree --reset HEAD
+$ git update-index --refresh
 ----------------
 
 which will force a total index re-build from the tree pointed to by `HEAD`.
 It resets the index contents to `HEAD`, and then the `git-update-index`
 makes sure to match up all index entries with the checked-out files.
 If the original repository had uncommitted changes in its
-working tree, `git-update-index --refresh` notices them and
+working tree, `git update-index --refresh` notices them and
 tells you they need to be updated.
 
 The above can also be written as simply
@@ -691,7 +690,7 @@ and in fact a lot of the common git command combinations can be scripted
 with the `git xyz` interfaces.  You can learn things by just looking
 at what the various git scripts do.  For example, `git reset` used to be
 the above two lines implemented in `git-reset`, but some things like
-`git status` and `git commit` are slightly more complex scripts around
+`git-status` and `git-commit` are slightly more complex scripts around
 the basic git commands.
 
 Many (most?) public remote repositories will not contain any of
@@ -714,7 +713,7 @@ $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
 followed by
 
 ----------------
-$ git-read-tree HEAD
+$ git read-tree HEAD
 ----------------
 
 to populate the index. However, now you have populated the index, and
@@ -723,14 +722,14 @@ actually have any of the working tree files to work on. To get
 those, you'd check them out with
 
 ----------------
-$ git-checkout-index -u -a
+$ git checkout-index -u -a
 ----------------
 
 where the `-u` flag means that you want the checkout to keep the index
 up-to-date (so that you don't have to refresh it afterward), and the
 `-a` flag means "check out all files" (if you have a stale copy or an
 older version of a checked out tree you may also need to add the `-f`
-flag first, to tell git-checkout-index to *force* overwriting of any old
+flag first, to tell `git-checkout-index` to *force* overwriting of any old
 files).
 
 Again, this can all be simplified with
@@ -840,7 +839,7 @@ $ git commit -m "Some work." -i hello
 ------------------------------------------------
 
 Here, we just added another line to `hello`, and we used a shorthand for
-doing both `git-update-index hello` and `git commit` by just giving the
+doing both `git update-index hello` and `git commit` by just giving the
 filename directly to `git commit`, with an `-i` flag (it tells
 git to 'include' that file in addition to what you have done to
 the index file so far when making the commit).  The `-m` flag is to give the
@@ -926,7 +925,7 @@ $ git commit -i hello
 
 which will very loudly warn you that you're now committing a merge
 (which is correct, so never mind), and you can write a small merge
-message about your adventures in git-merge-land.
+message about your adventures in `git-merge`-land.
 
 After you're done, start up `gitk \--all` to see graphically what the
 history looks like. Notice that `mybranch` still exists, and you can
@@ -939,7 +938,7 @@ Another useful tool, especially if you do not always work in X-Window
 environment, is `git show-branch`.
 
 ------------------------------------------------
-$ git-show-branch --topo-order --more=1 master mybranch
+$ git show-branch --topo-order --more=1 master mybranch
 * [master] Merge work in mybranch
  ! [mybranch] Some work.
 --
@@ -964,25 +963,25 @@ commits from the master branch.  The string inside brackets
 before the commit log message is a short name you can use to
 name the commit.  In the above example, 'master' and 'mybranch'
 are branch heads.  'master^' is the first parent of 'master'
-branch head.  Please see 'git-rev-parse' documentation if you
+branch head.  Please see linkgit:git-rev-parse[1] if you want to
 see more complex cases.
 
 [NOTE]
-Without the '--more=1' option, 'git-show-branch' would not output the
+Without the '--more=1' option, `git-show-branch` would not output the
 '[master^]' commit, as '[mybranch]' commit is a common ancestor of
-both 'master' and 'mybranch' tips.  Please see 'git-show-branch'
-documentation for details.
+both 'master' and 'mybranch' tips.  Please see linkgit:git-show-branch[1]
+for details.
 
 [NOTE]
 If there were more commits on the 'master' branch after the merge, the
-merge commit itself would not be shown by 'git-show-branch' by
+merge commit itself would not be shown by `git-show-branch` by
 default.  You would need to provide '--sparse' option to make the
 merge commit visible in this case.
 
 Now, let's pretend you are the one who did all the work in
 `mybranch`, and the fruit of your hard work has finally been merged
 to the `master` branch. Let's go back to `mybranch`, and run
-`git merge` to get the "upstream changes" back to your branch.
+`git-merge` to get the "upstream changes" back to your branch.
 
 ------------
 $ git checkout mybranch
@@ -1199,7 +1198,7 @@ algorithm.  First, it finds the common ancestor between them.
 The command it uses is `git-merge-base`:
 
 ------------
-$ mb=$(git-merge-base HEAD mybranch)
+$ mb=$(git merge-base HEAD mybranch)
 ------------
 
 The command writes the commit object name of the common ancestor
@@ -1209,7 +1208,7 @@ ancestor commit is the "New day." commit in this case.  You can
 tell it by:
 
 ------------
-$ git-name-rev $mb
+$ git name-rev $mb
 my-first-tag
 ------------
 
@@ -1217,7 +1216,7 @@ After finding out a common ancestor commit, the second step is
 this:
 
 ------------
-$ git-read-tree -m -u $mb HEAD mybranch
+$ git read-tree -m -u $mb HEAD mybranch
 ------------
 
 This is the same `git-read-tree` command we have already seen,
@@ -1236,7 +1235,7 @@ trees are left in non-zero stages.  At this point, you can
 inspect the index file with this command:
 
 ------------
-$ git-ls-files --stage
+$ git ls-files --stage
 100644 7f8b141b65fdcee47321e399a2598a235a032422 0	example
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1	hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2	hello
@@ -1253,7 +1252,7 @@ stages.
 To look at only non-zero stages, use `\--unmerged` flag:
 
 ------------
-$ git-ls-files --unmerged
+$ git ls-files --unmerged
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1	hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2	hello
 100644 cc44c73eb783565da5831b4d820c962954019b69 3	hello
@@ -1265,7 +1264,7 @@ file, using 3-way merge.  This is done by giving
 `git-merge-index` command:
 
 ------------
-$ git-merge-index git-merge-one-file hello
+$ git merge-index git-merge-one-file hello
 Auto-merging hello.
 merge: warning: conflicts during merge
 ERROR: Merge conflict in hello.
@@ -1283,7 +1282,7 @@ the working tree..  This can be seen if you run `ls-files
 --stage` again at this point:
 
 ------------
-$ git-ls-files --stage
+$ git ls-files --stage
 100644 7f8b141b65fdcee47321e399a2598a235a032422 0	example
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1	hello
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2	hello
@@ -1291,9 +1290,9 @@ $ git-ls-files --stage
 ------------
 
 This is the state of the index file and the working file after
-`git merge` returns control back to you, leaving the conflicting
+`git-merge` returns control back to you, leaving the conflicting
 merge for you to resolve.  Notice that the path `hello` is still
-unmerged, and what you see with `git diff` at this point is
+unmerged, and what you see with `git-diff` at this point is
 differences since stage 2 (i.e. your version).
 
 
@@ -1330,7 +1329,7 @@ into it later. Obviously, this repository creation needs to be
 done only once.
 
 [NOTE]
-`git push` uses a pair of programs,
+`git-push` uses a pair of programs,
 `git-send-pack` on your local machine, and `git-receive-pack`
 on the remote machine. The communication between the two over
 the network internally uses an SSH connection.
@@ -1350,7 +1349,7 @@ Then, make that directory into a git repository by running
 `.git`, we do things slightly differently:
 
 ------------
-$ GIT_DIR=my-git.git git-init
+$ GIT_DIR=my-git.git git init
 ------------
 
 Make sure this directory is available for others you want your
@@ -1369,7 +1368,7 @@ your login shell is `bash`, only `.bashrc` is read and not
 If you plan to publish this repository to be accessed over http,
 you should do `chmod +x my-git.git/hooks/post-update` at this
 point.  This makes sure that every time you push into this
-repository, `git-update-server-info` is run.
+repository, `git update-server-info` is run.
 
 Your "public repository" is now ready to accept your changes.
 Come back to the machine you have your private repository. From
@@ -1496,9 +1495,9 @@ keeps the necessary files up-to-date.
 3. Push into the public repository from your primary
    repository.
 
-4. `git repack` the public repository. This establishes a big
+4. `git-repack` the public repository. This establishes a big
    pack that contains the initial set of objects as the
-   baseline, and possibly `git prune` if the transport
+   baseline, and possibly `git-prune` if the transport
    used for pulling from your repository supports packed
    repositories.
 
@@ -1512,14 +1511,14 @@ You can repack this private repository whenever you feel like.
 6. Push your changes to the public repository, and announce it
    to the public.
 
-7. Every once in a while, "git repack" the public repository.
+7. Every once in a while, "git-repack" the public repository.
    Go back to step 5. and continue working.
 
 
 A recommended work cycle for a "subsystem maintainer" who works
 on that project and has an own "public repository" goes like this:
 
-1. Prepare your work repository, by `git clone` the public
+1. Prepare your work repository, by `git-clone` the public
    repository of the "project lead". The URL used for the
    initial cloning is stored in the remote.origin.url
    configuration variable.
@@ -1534,7 +1533,7 @@ on that project and has an own "public repository" goes like this:
    point at the repository you are borrowing from.
 
 4. Push into the public repository from your primary
-   repository. Run `git repack`, and possibly `git prune` if the
+   repository. Run `git-repack`, and possibly `git-prune` if the
    transport used for pulling from your repository supports
    packed repositories.
 
@@ -1551,7 +1550,7 @@ like.
    "project lead" and possibly your "sub-subsystem
    maintainers" to pull from it.
 
-7. Every once in a while, `git repack` the public repository.
+7. Every once in a while, `git-repack` the public repository.
    Go back to step 5. and continue working.
 
 
@@ -1559,7 +1558,7 @@ A recommended work cycle for an "individual developer" who does
 not have a "public" repository is somewhat different. It goes
 like this:
 
-1. Prepare your work repository, by `git clone` the public
+1. Prepare your work repository, by `git-clone` the public
    repository of the "project lead" (or a "subsystem
    maintainer", if you work on a subsystem). The URL used for
    the initial cloning is stored in the remote.origin.url
@@ -1589,7 +1588,7 @@ suggested in the previous section may be new to you. You do not
 have to worry. git supports "shared public repository" style of
 cooperation you are probably more familiar with as well.
 
-See linkgit:gitcvs-migration[7][git for CVS users] for the details.
+See linkgit:gitcvs-migration[7] for the details.
 
 Bundling your work together
 ---------------------------
diff --git a/gitcvs-migration.html b/gitcvs-migration.html
index 3bd40f461..7c914eb0e 100644
--- a/gitcvs-migration.html
+++ b/gitcvs-migration.html
@@ -281,9 +281,9 @@ a full copy of the project history, and no repository is inherently more
 important than any other.  However, you can emulate the CVS model by
 designating a single shared repository which people can synchronize with;
 this document explains how to do that.</p>
-<p>Some basic familiarity with git is required.  This
-<a href="gittutorial.html">gittutorial(7)</a>[tutorial introduction to git] and the
-<a href="gitglossary.html">gitglossary(7)</a>[git glossary] should be sufficient.</p>
+<p>Some basic familiarity with git is required. Having gone through
+<a href="gittutorial.html">gittutorial(7)</a> and
+<a href="gitglossary.html">gitglossary(7)</a> should be sufficient.</p>
 </div>
 <h2>Developing against a shared repository</h2>
 <div class="sectionbody">
@@ -310,24 +310,24 @@ them first before running git pull.</p>
 </td>
 <td class="content">
 <p>The <tt>pull</tt> command knows where to get updates from because of certain
-configuration variables that were set by the first <tt>git clone</tt>
+configuration variables that were set by the first <tt>git-clone</tt>
 command; see <tt>git config -l</tt> and the <a href="git-config.html">git-config(1)</a> man
 page for details.</p>
 </td>
 </tr></table>
 </div>
 <p>You can update the shared repository with your changes by first committing
-your changes, and then using the <a href="git-push.html">git-push(1)</a> command:</p>
+your changes, and then using the <tt>git-push</tt> command:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git push origin master</tt></pre>
 </div></div>
 <p>to "push" those commits to the shared repository.  If someone else has
-updated the repository more recently, <tt>git push</tt>, like <tt>cvs commit</tt>, will
+updated the repository more recently, <tt>git-push</tt>, like <tt>cvs commit</tt>, will
 complain, in which case you must pull any changes before attempting the
 push again.</p>
-<p>In the <tt>git push</tt> command above we specify the name of the remote branch
-to update (<tt>master</tt>).  If we leave that out, <tt>git push</tt> tries to update
+<p>In the <tt>git-push</tt> command above we specify the name of the remote branch
+to update (<tt>master</tt>).  If we leave that out, <tt>git-push</tt> tries to update
 any branches in the remote repository that have the same name as a branch
 in the local repository.  So the last <tt>push</tt> can be done with either of:</p>
 <div class="listingblock">
@@ -341,8 +341,8 @@ other than <tt>master</tt>.</p>
 <h2>Setting Up a Shared Repository</h2>
 <div class="sectionbody">
 <p>We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-<a href="gittutorial.html">gittutorial(7)</a>[tutorial]), or imported from an already existing CVS
+possibly created from scratch or from a tarball (see
+<a href="gittutorial.html">gittutorial(7)</a>), or imported from an already existing CVS
 repository (see the next section).</p>
 <p>Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
 repository (a repository without a working tree) and fetch your project into
@@ -373,7 +373,7 @@ they create are writable and searchable by other group members.</p>
 <p>First, install version 2.1 or higher of cvsps from
 <a href="http://www.cobite.com/cvsps/">http://www.cobite.com/cvsps/</a> and make
 sure it is in your path.  Then cd to a checked out CVS working directory
-of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p>
+of the project you are interested in and run <tt>git-cvsimport</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git cvsimport -C &lt;destination&gt; &lt;module&gt;</tt></pre>
@@ -398,7 +398,7 @@ necessary.</p>
 <div class="sectionbody">
 <p>Git allows you to specify scripts called "hooks" to be run at certain
 points.  You can use these, for example, to send all commits to the shared
-repository to a mailing list.  See <a href="githooks.html">githooks(5)</a>[Hooks used by git].</p>
+repository to a mailing list.  See <a href="githooks.html">githooks(5)</a>.</p>
 <p>You can enforce finer grained permissions using update hooks.  See
 <a href="howto/update-hook-example.txt">Controlling access to branches using
 update hooks</a>.</p>
@@ -442,7 +442,7 @@ repositories without the need for a central maintainer.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:31 UTC
+Last updated 02-Jul-2008 03:02:12 UTC
 </div>
 </div>
 </body>
diff --git a/gitcvs-migration.txt b/gitcvs-migration.txt
index 1db3f5294..4dc7ec540 100644
--- a/gitcvs-migration.txt
+++ b/gitcvs-migration.txt
@@ -18,9 +18,9 @@ important than any other.  However, you can emulate the CVS model by
 designating a single shared repository which people can synchronize with;
 this document explains how to do that.
 
-Some basic familiarity with git is required.  This
-linkgit:gittutorial[7][tutorial introduction to git] and the
-linkgit:gitglossary[7][git glossary] should be sufficient.
+Some basic familiarity with git is required. Having gone through
+linkgit:gittutorial[7] and
+linkgit:gitglossary[7] should be sufficient.
 
 Developing against a shared repository
 --------------------------------------
@@ -47,25 +47,25 @@ them first before running git pull.
 [NOTE]
 ================================
 The `pull` command knows where to get updates from because of certain
-configuration variables that were set by the first `git clone`
+configuration variables that were set by the first `git-clone`
 command; see `git config -l` and the linkgit:git-config[1] man
 page for details.
 ================================
 
 You can update the shared repository with your changes by first committing
-your changes, and then using the linkgit:git-push[1] command:
+your changes, and then using the `git-push` command:
 
 ------------------------------------------------
 $ git push origin master
 ------------------------------------------------
 
 to "push" those commits to the shared repository.  If someone else has
-updated the repository more recently, `git push`, like `cvs commit`, will
+updated the repository more recently, `git-push`, like `cvs commit`, will
 complain, in which case you must pull any changes before attempting the
 push again.
 
-In the `git push` command above we specify the name of the remote branch
-to update (`master`).  If we leave that out, `git push` tries to update
+In the `git-push` command above we specify the name of the remote branch
+to update (`master`).  If we leave that out, `git-push` tries to update
 any branches in the remote repository that have the same name as a branch
 in the local repository.  So the last `push` can be done with either of:
 
@@ -81,8 +81,8 @@ Setting Up a Shared Repository
 ------------------------------
 
 We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-linkgit:gittutorial[7][tutorial]), or imported from an already existing CVS
+possibly created from scratch or from a tarball (see
+linkgit:gittutorial[7]), or imported from an already existing CVS
 repository (see the next section).
 
 Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
@@ -118,7 +118,7 @@ Importing a CVS archive
 First, install version 2.1 or higher of cvsps from
 link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
 sure it is in your path.  Then cd to a checked out CVS working directory
-of the project you are interested in and run linkgit:git-cvsimport[1]:
+of the project you are interested in and run `git-cvsimport`:
 
 -------------------------------------------
 $ git cvsimport -C <destination> <module>
@@ -148,7 +148,7 @@ Advanced Shared Repository Management
 
 Git allows you to specify scripts called "hooks" to be run at certain
 points.  You can use these, for example, to send all commits to the shared
-repository to a mailing list.  See linkgit:githooks[5][Hooks used by git].
+repository to a mailing list.  See linkgit:githooks[5].
 
 You can enforce finer grained permissions using update hooks.  See
 link:howto/update-hook-example.txt[Controlling access to branches using
diff --git a/gitdiffcore.html b/gitdiffcore.html
index 982335367..600ba7d8a 100644
--- a/gitdiffcore.html
+++ b/gitdiffcore.html
@@ -276,21 +276,21 @@ gitdiffcore(7) Manual Page
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>The diff commands git-diff-index, git-diff-files, and git-diff-tree
+<p>The diff commands <tt>git-diff-index</tt>, <tt>git-diff-files</tt>, and <tt>git-diff-tree</tt>
 can be told to manipulate differences they find in
-unconventional ways before showing diff(1) output.  The manipulation
+unconventional ways before showing <tt>diff</tt> output.  The manipulation
 is collectively called "diffcore transformation".  This short note
 describes what they are and how to use them to produce diff outputs
 that are easier to understand than the conventional kind.</p>
 </div>
 <h2>The chain of operation</h2>
 <div class="sectionbody">
-<p>The git-diff-* family works by first comparing two sets of
+<p>The <tt>git-diff-&#42;</tt> family works by first comparing two sets of
 files:</p>
 <ul>
 <li>
 <p>
-git-diff-index compares contents of a "tree" object and the
+<tt>git-diff-index</tt> compares contents of a "tree" object and the
    working directory (when <em>--cached</em> flag is not used) or a
    "tree" object and the index file (when <em>--cached</em> flag is
    used);
@@ -298,13 +298,13 @@ git-diff-index compares contents of a "tree" object and the
 </li>
 <li>
 <p>
-git-diff-files compares contents of the index file and the
+<tt>git-diff-files</tt> compares contents of the index file and the
    working directory;
 </p>
 </li>
 <li>
 <p>
-git-diff-tree compares contents of two "tree" objects;
+<tt>git-diff-tree</tt> compares contents of two "tree" objects;
 </p>
 </li>
 </ul>
@@ -356,19 +356,19 @@ diffcore-order
 </p>
 </li>
 </ul>
-<p>These are applied in sequence.  The set of filepairs git-diff-*
+<p>These are applied in sequence.  The set of filepairs <tt>git-diff-&#42;</tt>
 commands find are used as the input to diffcore-pathspec, and
 the output from diffcore-pathspec is used as the input to the
 next transformation.  The final result is then passed to the
 output routine and generates either diff-raw format (see Output
-format sections of the manual for git-diff-* commands) or
+format sections of the manual for <tt>git-diff-&#42;</tt> commands) or
 diff-patch format.</p>
 </div>
 <h2>diffcore-pathspec: For Ignoring Files Outside Our Consideration</h2>
 <div class="sectionbody">
 <p>The first transformation in the chain is diffcore-pathspec, and
 is controlled by giving the pathname parameters to the
-git-diff-* commands on the command line.  The pathspec is used
+<tt>git-diff-&#42;</tt> commands on the command line.  The pathspec is used
 to limit the world diff operates in.  It removes the filepairs
 outside the specified set of pathnames.  E.g. If the input set
 of filepairs included:</p>
@@ -376,10 +376,10 @@ of filepairs included:</p>
 <div class="content">
 <pre><tt>:100644 100644 bcd1234... 0123456... M junkfile</tt></pre>
 </div></div>
-<p>but the command invocation was "git-diff-files myfile", then the
+<p>but the command invocation was <tt>git diff-files myfile</tt>, then the
 junkfile entry would be removed from the list because only "myfile"
 is under consideration.</p>
-<p>Implementation note.  For performance reasons, git-diff-tree
+<p>Implementation note.  For performance reasons, <tt>git-diff-tree</tt>
 uses the pathname parameters on the command line to cull set of
 filepairs it feeds the diffcore mechanism itself, and does not
 use diffcore-pathspec, but the end result is the same.</p>
@@ -387,7 +387,7 @@ use diffcore-pathspec, but the end result is the same.</p>
 <h2>diffcore-break: For Splitting Up "Complete Rewrites"</h2>
 <div class="sectionbody">
 <p>The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the git-diff-* commands.  This is
+controlled by the -B option to the <tt>git-diff-&#42;</tt> commands.  This is
 used to detect a filepair that represents "complete rewrite" and
 break such filepair into two filepairs that represent delete and
 create.  E.g.  If the input contained this filepair:</p>
@@ -419,7 +419,7 @@ after "-B" option (e.g. "-B75" to tell it to use 75%).</p>
 <div class="sectionbody">
 <p>This transformation is used to detect renames and copies, and is
 controlled by the -M option (to detect renames) and the -C option
-(to detect copies as well) to the git-diff-* commands.  If the
+(to detect copies as well) to the <tt>git-diff-&#42;</tt> commands.  If the
 input contained these filepairs:</p>
 <div class="listingblock">
 <div class="content">
@@ -459,11 +459,11 @@ a similarity score different from the default of 50% by giving a
 number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
 8/10 = 80%).</p>
 <p>Note.  When the "-C" option is used with <tt>--find-copies-harder</tt>
-option, git-diff-* commands feed unmodified filepairs to
+option, <tt>git-diff-&#42;</tt> commands feed unmodified filepairs to
 diffcore mechanism as well as modified ones.  This lets the copy
 detector consider unmodified files as copy source candidates at
 the expense of making it slower.  Without <tt>--find-copies-harder</tt>,
-git-diff-* commands can detect copies only if the file that was
+<tt>git-diff-&#42;</tt> commands can detect copies only if the file that was
 copied happened to have been modified in the same changeset.</p>
 </div>
 <h2>diffcore-merge-broken: For Putting "Complete Rewrites" Back Together</h2>
@@ -515,7 +515,7 @@ version prefixed with <em>+</em>.</p>
 <div class="sectionbody">
 <p>This transformation is used to find filepairs that represent
 changes that touch a specified string, and is controlled by the
--S option and the <tt>--pickaxe-all</tt> option to the git-diff-*
+-S option and the <tt>--pickaxe-all</tt> option to the <tt>git-diff-&#42;</tt>
 commands.</p>
 <p>When diffcore-pickaxe is in use, it checks if there are
 filepairs whose "original" side has the specified string and
@@ -534,7 +534,7 @@ changeset easier.</p>
 <div class="sectionbody">
 <p>This is used to reorder the filepairs according to the user's
 (or project's) taste, and is controlled by the -O option to the
-git-diff-* commands.</p>
+<tt>git-diff-&#42;</tt> commands.</p>
 <p>This takes a text file each of whose lines is a shell glob
 pattern.  Filepairs that match a glob pattern on an earlier line
 in the file are output before ones that match a later line, and
@@ -568,7 +568,7 @@ t</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:34 UTC
+Last updated 02-Jul-2008 03:02:13 UTC
 </div>
 </div>
 </body>
diff --git a/gitdiffcore.txt b/gitdiffcore.txt
index 4d56c8526..0b7daeda2 100644
--- a/gitdiffcore.txt
+++ b/gitdiffcore.txt
@@ -12,9 +12,9 @@ git diff *
 DESCRIPTION
 -----------
 
-The diff commands git-diff-index, git-diff-files, and git-diff-tree
+The diff commands `git-diff-index`, `git-diff-files`, and `git-diff-tree`
 can be told to manipulate differences they find in
-unconventional ways before showing diff(1) output.  The manipulation
+unconventional ways before showing `diff` output.  The manipulation
 is collectively called "diffcore transformation".  This short note
 describes what they are and how to use them to produce diff outputs
 that are easier to understand than the conventional kind.
@@ -23,18 +23,18 @@ that are easier to understand than the conventional kind.
 The chain of operation
 ----------------------
 
-The git-diff-* family works by first comparing two sets of
+The `git-diff-{asterisk}` family works by first comparing two sets of
 files:
 
- - git-diff-index compares contents of a "tree" object and the
+ - `git-diff-index` compares contents of a "tree" object and the
    working directory (when '\--cached' flag is not used) or a
    "tree" object and the index file (when '\--cached' flag is
    used);
 
- - git-diff-files compares contents of the index file and the
+ - `git-diff-files` compares contents of the index file and the
    working directory;
 
- - git-diff-tree compares contents of two "tree" objects;
+ - `git-diff-tree` compares contents of two "tree" objects;
 
 In all of these cases, the commands themselves compare
 corresponding paths in the two sets of files.  The result of
@@ -61,12 +61,12 @@ into another list.  There are currently 6 such transformations:
 - diffcore-pickaxe
 - diffcore-order
 
-These are applied in sequence.  The set of filepairs git-diff-\*
+These are applied in sequence.  The set of filepairs `git-diff-{asterisk}`
 commands find are used as the input to diffcore-pathspec, and
 the output from diffcore-pathspec is used as the input to the
 next transformation.  The final result is then passed to the
 output routine and generates either diff-raw format (see Output
-format sections of the manual for git-diff-\* commands) or
+format sections of the manual for `git-diff-{asterisk}` commands) or
 diff-patch format.
 
 
@@ -75,7 +75,7 @@ diffcore-pathspec: For Ignoring Files Outside Our Consideration
 
 The first transformation in the chain is diffcore-pathspec, and
 is controlled by giving the pathname parameters to the
-git-diff-* commands on the command line.  The pathspec is used
+`git-diff-{asterisk}` commands on the command line.  The pathspec is used
 to limit the world diff operates in.  It removes the filepairs
 outside the specified set of pathnames.  E.g. If the input set
 of filepairs included:
@@ -84,11 +84,11 @@ of filepairs included:
 :100644 100644 bcd1234... 0123456... M junkfile
 ------------------------------------------------
 
-but the command invocation was "git-diff-files myfile", then the
+but the command invocation was `git diff-files myfile`, then the
 junkfile entry would be removed from the list because only "myfile"
 is under consideration.
 
-Implementation note.  For performance reasons, git-diff-tree
+Implementation note.  For performance reasons, `git-diff-tree`
 uses the pathname parameters on the command line to cull set of
 filepairs it feeds the diffcore mechanism itself, and does not
 use diffcore-pathspec, but the end result is the same.
@@ -98,7 +98,7 @@ diffcore-break: For Splitting Up "Complete Rewrites"
 ----------------------------------------------------
 
 The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the git-diff-* commands.  This is
+controlled by the -B option to the `git-diff-{asterisk}` commands.  This is
 used to detect a filepair that represents "complete rewrite" and
 break such filepair into two filepairs that represent delete and
 create.  E.g.  If the input contained this filepair:
@@ -134,7 +134,7 @@ diffcore-rename: For Detection Renames and Copies
 
 This transformation is used to detect renames and copies, and is
 controlled by the -M option (to detect renames) and the -C option
-(to detect copies as well) to the git-diff-* commands.  If the
+(to detect copies as well) to the `git-diff-{asterisk}` commands.  If the
 input contained these filepairs:
 
 ------------------------------------------------
@@ -179,11 +179,11 @@ number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
 8/10 = 80%).
 
 Note.  When the "-C" option is used with `\--find-copies-harder`
-option, git-diff-\* commands feed unmodified filepairs to
+option, `git-diff-{asterisk}` commands feed unmodified filepairs to
 diffcore mechanism as well as modified ones.  This lets the copy
 detector consider unmodified files as copy source candidates at
 the expense of making it slower.  Without `\--find-copies-harder`,
-git-diff-\* commands can detect copies only if the file that was
+`git-diff-{asterisk}` commands can detect copies only if the file that was
 copied happened to have been modified in the same changeset.
 
 
@@ -234,7 +234,7 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
 
 This transformation is used to find filepairs that represent
 changes that touch a specified string, and is controlled by the
--S option and the `\--pickaxe-all` option to the git-diff-*
+-S option and the `\--pickaxe-all` option to the `git-diff-{asterisk}`
 commands.
 
 When diffcore-pickaxe is in use, it checks if there are
@@ -257,7 +257,7 @@ diffcore-order: For Sorting the Output Based on Filenames
 
 This is used to reorder the filepairs according to the user's
 (or project's) taste, and is controlled by the -O option to the
-git-diff-* commands.
+`git-diff-{asterisk}` commands.
 
 This takes a text file each of whose lines is a shell glob
 pattern.  Filepairs that match a glob pattern on an earlier line
diff --git a/gitglossary.html b/gitglossary.html
index ec841d027..11b175592 100644
--- a/gitglossary.html
+++ b/gitglossary.html
@@ -1104,7 +1104,7 @@ This commit is referred to as a "merge commit", or sometimes just a
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:32 UTC
+Last updated 02-Jul-2008 03:02:12 UTC
 </div>
 </div>
 </body>
diff --git a/githooks.html b/githooks.html
index 11cf4971c..f130c11a8 100644
--- a/githooks.html
+++ b/githooks.html
@@ -384,7 +384,7 @@ properties.</p>
 </div>
 <h2>post-merge</h2>
 <div class="sectionbody">
-<p>This hook is invoked by <tt>git-merge</tt>, which happens when a <tt>git pull</tt>
+<p>This hook is invoked by <tt>git-merge</tt>, which happens when a <tt>git-pull</tt>
 is done on a local repository.  The hook takes a single parameter, a status
 flag specifying whether or not the merge being done was a squash merge.
 This hook cannot affect the outcome of <tt>git-merge</tt> and is not executed,
@@ -397,7 +397,7 @@ for an example of how to do this.</p>
 <h2><a id="pre-receive"></a>pre-receive</h2>
 <div class="sectionbody">
 <p>This hook is invoked by <tt>git-receive-pack</tt> on the remote repository,
-which happens when a <tt>git push</tt> is done on a local repository.
+which happens when a <tt>git-push</tt> is done on a local repository.
 Just before starting to update refs on the remote repository, the
 pre-receive hook is invoked.  Its exit status determines the success
 or failure of the update.</p>
@@ -422,7 +422,7 @@ for the user.</p>
 <h2><a id="update"></a>update</h2>
 <div class="sectionbody">
 <p>This hook is invoked by <tt>git-receive-pack</tt> on the remote repository,
-which happens when a <tt>git push</tt> is done on a local repository.
+which happens when a <tt>git-push</tt> is done on a local repository.
 Just before updating the ref on the remote repository, the update hook
 is invoked.  Its exit status determines the success or failure of
 the ref update.</p>
@@ -469,7 +469,7 @@ unannotated tags to be pushed.</p>
 <h2><a id="post-receive"></a>post-receive</h2>
 <div class="sectionbody">
 <p>This hook is invoked by <tt>git-receive-pack</tt> on the remote repository,
-which happens when a <tt>git push</tt> is done on a local repository.
+which happens when a <tt>git-push</tt> is done on a local repository.
 It executes on the remote repository once after all the refs have
 been updated.</p>
 <p>This hook executes once for the receive operation.  It takes no
@@ -492,7 +492,7 @@ emails.</p>
 <h2><a id="post-update"></a>post-update</h2>
 <div class="sectionbody">
 <p>This hook is invoked by <tt>git-receive-pack</tt> on the remote repository,
-which happens when a <tt>git push</tt> is done on a local repository.
+which happens when a <tt>git-push</tt> is done on a local repository.
 It executes on the remote repository once after all the refs have
 been updated.</p>
 <p>It takes a variable number of parameters, each of which is the
@@ -526,7 +526,7 @@ to abort.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 25-Jun-2008 08:07:17 UTC
+Last updated 02-Jul-2008 03:02:10 UTC
 </div>
 </div>
 </body>
diff --git a/githooks.txt b/githooks.txt
index 262a4f162..6a0d098f7 100644
--- a/githooks.txt
+++ b/githooks.txt
@@ -147,7 +147,7 @@ properties.
 post-merge
 -----------
 
-This hook is invoked by `git-merge`, which happens when a `git pull`
+This hook is invoked by `git-merge`, which happens when a `git-pull`
 is done on a local repository.  The hook takes a single parameter, a status
 flag specifying whether or not the merge being done was a squash merge.
 This hook cannot affect the outcome of `git-merge` and is not executed,
@@ -163,7 +163,7 @@ pre-receive
 -----------
 
 This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
 Just before starting to update refs on the remote repository, the
 pre-receive hook is invoked.  Its exit status determines the success
 or failure of the update.
@@ -192,7 +192,7 @@ update
 ------
 
 This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
 Just before updating the ref on the remote repository, the update hook
 is invoked.  Its exit status determines the success or failure of
 the ref update.
@@ -235,7 +235,7 @@ post-receive
 ------------
 
 This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
 It executes on the remote repository once after all the refs have
 been updated.
 
@@ -265,7 +265,7 @@ post-update
 -----------
 
 This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
+which happens when a `git-push` is done on a local repository.
 It executes on the remote repository once after all the refs have
 been updated.
 
diff --git a/gitignore.html b/gitignore.html
index 0c1f7e364..f5292ed33 100644
--- a/gitignore.html
+++ b/gitignore.html
@@ -326,10 +326,10 @@ ignore in all situations (e.g., backup or temporary files generated by
 the user's editor of choice) generally go into a file specified by
 <tt>core.excludesfile</tt> in the user's <tt>~/.gitconfig</tt>.</p>
 <p>The underlying git plumbing tools, such as
-<a href="git-ls-files.html">git-ls-files(1)</a> and <a href="git-read-tree.html">git-read-tree(1)</a>, read
+<tt>git-ls-files</tt> and <tt>git-read-tree</tt>, read
 <tt>gitignore</tt> patterns specified by command-line options, or from
 files specified by command-line options.  Higher-level git
-tools, such as <a href="git-status.html">git-status(1)</a> and <a href="git-add.html">git-add(1)</a>,
+tools, such as <tt>git-status</tt> and <tt>git-add</tt>,
 use patterns from the sources specified above.</p>
 <p>Patterns have the following format:</p>
 <ul>
@@ -385,7 +385,7 @@ Otherwise, git treats the pattern as a shell glob suitable
 <p>An example:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>    $ git-status
+<pre><tt>    $ git status
     [...]
     # Untracked files:
     [...]
@@ -403,7 +403,7 @@ Otherwise, git treats the pattern as a shell glob suitable
     *.html
     # except foo.html which is maintained by hand
     !foo.html
-    $ git-status
+    $ git status
     [...]
     # Untracked files:
     [...]
@@ -433,7 +433,7 @@ Frank Lichtenheld, and the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:26 UTC
+Last updated 02-Jul-2008 03:02:10 UTC
 </div>
 </div>
 </body>
diff --git a/gitignore.txt b/gitignore.txt
index 2881c9cb9..cafdac7e3 100644
--- a/gitignore.txt
+++ b/gitignore.txt
@@ -51,10 +51,10 @@ the user's editor of choice) generally go into a file specified by
 `core.excludesfile` in the user's `~/.gitconfig`.
 
 The underlying git plumbing tools, such as
-linkgit:git-ls-files[1] and linkgit:git-read-tree[1], read
+`git-ls-files` and `git-read-tree`, read
 `gitignore` patterns specified by command-line options, or from
 files specified by command-line options.  Higher-level git
-tools, such as linkgit:git-status[1] and linkgit:git-add[1],
+tools, such as `git-status` and `git-add`,
 use patterns from the sources specified above.
 
 Patterns have the following format:
@@ -92,7 +92,7 @@ Patterns have the following format:
 An example:
 
 --------------------------------------------------------------
-    $ git-status
+    $ git status
     [...]
     # Untracked files:
     [...]
@@ -110,7 +110,7 @@ An example:
     *.html
     # except foo.html which is maintained by hand
     !foo.html
-    $ git-status
+    $ git status
     [...]
     # Untracked files:
     [...]
diff --git a/gitk.html b/gitk.html
index 9cf30ae59..052195e91 100644
--- a/gitk.html
+++ b/gitk.html
@@ -286,7 +286,8 @@ git repository.</p>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
 <p>To control which revisions to shown, the command takes options applicable to
-the <a href="git-rev-list.html">git-rev-list(1)</a> command. This manual page describes only the most
+the <tt>git-rev-list</tt> command (see <a href="git-rev-list.html">git-rev-list(1)</a>).
+This manual page describes only the most
 frequently used options.</p>
 <dl>
 <dt>
@@ -443,7 +444,7 @@ such as display options, font, and colors.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 22:47:04 UTC
+Last updated 02-Jul-2008 03:02:08 UTC
 </div>
 </div>
 </body>
diff --git a/gitk.txt b/gitk.txt
index f843f39bf..03688bfa6 100644
--- a/gitk.txt
+++ b/gitk.txt
@@ -22,7 +22,8 @@ git repository.
 OPTIONS
 -------
 To control which revisions to shown, the command takes options applicable to
-the linkgit:git-rev-list[1] command. This manual page describes only the most
+the `git-rev-list` command (see linkgit:git-rev-list[1]).
+This manual page describes only the most
 frequently used options.
 
 -n <number>::
diff --git a/gitmodules.html b/gitmodules.html
index ef2a967d4..cc16923fa 100644
--- a/gitmodules.html
+++ b/gitmodules.html
@@ -337,7 +337,7 @@ submodules an url is specified which can be used for cloning the submodules.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:27 UTC
+Last updated 02-Jul-2008 03:02:10 UTC
 </div>
 </div>
 </body>
diff --git a/gitrepository-layout.html b/gitrepository-layout.html
index dc1718510..5e37a51a3 100644
--- a/gitrepository-layout.html
+++ b/gitrepository-layout.html
@@ -365,7 +365,7 @@ objects/info/packs
         are available in this object store.  Whenever a pack is
         added or removed, <tt>git update-server-info</tt> should be run
         to keep this file up-to-date if the repository is
-        published for dumb transports.  <tt>git repack</tt> does this
+        published for dumb transports.  <tt>git-repack</tt> does this
         by default.
 </p>
 </dd>
@@ -401,7 +401,7 @@ refs
 <dd>
 <p>
         References are stored in subdirectories of this
-        directory.  The <tt>git prune</tt> command knows to keep
+        directory.  The <tt>git-prune</tt> command knows to keep
         objects reachable from refs found in this directory and
         its subdirectories.
 </p>
@@ -470,7 +470,7 @@ branches
 <dd>
 <p>
         A slightly deprecated way to store shorthands to be used
-        to specify URL to <tt>git fetch</tt>, <tt>git pull</tt> and <tt>git push</tt>
+        to specify URL to <tt>git-fetch</tt>, <tt>git-pull</tt> and <tt>git-push</tt>
         commands is to store a file in <tt>branches/&lt;name&gt;</tt> and
         give <em>name</em> to these commands in place of <em>repository</em>
         argument.
@@ -483,9 +483,9 @@ hooks
 <p>
         Hooks are customization scripts used by various git
         commands.  A handful of sample hooks are installed when
-        <tt>git init</tt> is run, but all of them are disabled by
+        <tt>git-init</tt> is run, but all of them are disabled by
         default.  To enable, they need to be made executable.
-        Read <a href="githooks.html">githooks(5)</a>[hooks] for more details about
+        Read <a href="githooks.html">githooks(5)</a> for more details about
         each hook.
 </p>
 </dd>
@@ -515,10 +515,10 @@ info/refs
         This file helps dumb transports discover what refs are
         available in this repository.  If the repository is
         published for dumb transports, this file should be
-        regenerated by <tt>git update-server-info</tt> every time a tag
+        regenerated by <tt>git-update-server-info</tt> every time a tag
         or branch is created or modified.  This is normally done
         from the <tt>hooks/update</tt> hook, which is run by the
-        <tt>git-receive-pack</tt> command when you <tt>git push</tt> into the
+        <tt>git-receive-pack</tt> command when you <tt>git-push</tt> into the
         repository.
 </p>
 </dd>
@@ -542,8 +542,8 @@ info/exclude
 <p>
         This file, by convention among Porcelains, stores the
         exclude pattern list. <tt>.gitignore</tt> is the per-directory
-        ignore file.  <tt>git status</tt>, <tt>git add</tt>, <tt>git rm</tt> and <tt>git
-        clean</tt> look at it but the core git commands do not look
+        ignore file.  <tt>git-status</tt>, <tt>git-add</tt>, <tt>git-rm</tt> and
+        <tt>git-clean</tt> look at it but the core git commands do not look
         at it.  See also: <a href="gitignore.html">gitignore(5)</a>.
 </p>
 </dd>
@@ -553,8 +553,8 @@ remotes
 <dd>
 <p>
         Stores shorthands to be used to give URL and default
-        refnames to interact with remote repository to <tt>git
-        fetch</tt>, <tt>git pull</tt> and <tt>git push</tt> commands.
+        refnames to interact with remote repository to
+        <tt>git-fetch</tt>, <tt>git-pull</tt> and <tt>git-push</tt> commands.
 </p>
 </dd>
 <dt>
@@ -563,7 +563,7 @@ logs
 <dd>
 <p>
         Records of changes made to refs are stored in this
-        directory.  See the documentation on git-update-ref
+        directory.  See <a href="git-update-ref.html">git-update-ref(1)</a>
         for more information.
 </p>
 </dd>
@@ -612,7 +612,7 @@ shallow
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:28 UTC
+Last updated 02-Jul-2008 03:02:10 UTC
 </div>
 </div>
 </body>
diff --git a/gitrepository-layout.txt b/gitrepository-layout.txt
index 03c52ff52..ade812e0e 100644
--- a/gitrepository-layout.txt
+++ b/gitrepository-layout.txt
@@ -64,7 +64,7 @@ objects/info/packs::
 	are available in this object store.  Whenever a pack is
 	added or removed, `git update-server-info` should be run
 	to keep this file up-to-date if the repository is
-	published for dumb transports.  `git repack` does this
+	published for dumb transports.  `git-repack` does this
 	by default.
 
 objects/info/alternates::
@@ -85,7 +85,7 @@ objects/info/http-alternates::
 
 refs::
 	References are stored in subdirectories of this
-	directory.  The `git prune` command knows to keep
+	directory.  The `git-prune` command knows to keep
 	objects reachable from refs found in this directory and
 	its subdirectories.
 
@@ -125,7 +125,7 @@ details.
 
 branches::
 	A slightly deprecated way to store shorthands to be used
-	to specify URL to `git fetch`, `git pull` and `git push`
+	to specify URL to `git-fetch`, `git-pull` and `git-push`
 	commands is to store a file in `branches/<name>` and
 	give 'name' to these commands in place of 'repository'
 	argument.
@@ -133,9 +133,9 @@ branches::
 hooks::
 	Hooks are customization scripts used by various git
 	commands.  A handful of sample hooks are installed when
-	`git init` is run, but all of them are disabled by
+	`git-init` is run, but all of them are disabled by
 	default.  To enable, they need to be made executable.
-	Read linkgit:githooks[5][hooks] for more details about
+	Read linkgit:githooks[5] for more details about
 	each hook.
 
 index::
@@ -150,10 +150,10 @@ info/refs::
 	This file helps dumb transports discover what refs are
 	available in this repository.  If the repository is
 	published for dumb transports, this file should be
-	regenerated by `git update-server-info` every time a tag
+	regenerated by `git-update-server-info` every time a tag
 	or branch is created or modified.  This is normally done
 	from the `hooks/update` hook, which is run by the
-	`git-receive-pack` command when you `git push` into the
+	`git-receive-pack` command when you `git-push` into the
 	repository.
 
 info/grafts::
@@ -167,18 +167,18 @@ info/grafts::
 info/exclude::
 	This file, by convention among Porcelains, stores the
 	exclude pattern list. `.gitignore` is the per-directory
-	ignore file.  `git status`, `git add`, `git rm` and `git
-	clean` look at it but the core git commands do not look
+	ignore file.  `git-status`, `git-add`, `git-rm` and
+	`git-clean` look at it but the core git commands do not look
 	at it.  See also: linkgit:gitignore[5].
 
 remotes::
 	Stores shorthands to be used to give URL and default
-	refnames to interact with remote repository to `git
-	fetch`, `git pull` and `git push` commands.
+	refnames to interact with remote repository to
+	`git-fetch`, `git-pull` and `git-push` commands.
 
 logs::
 	Records of changes made to refs are stored in this
-	directory.  See the documentation on git-update-ref
+	directory.  See linkgit:git-update-ref[1]
 	for more information.
 
 logs/refs/heads/`name`::
diff --git a/gittutorial-2.html b/gittutorial-2.html
index 54c2c83e2..c24a9fdbf 100644
--- a/gittutorial-2.html
+++ b/gittutorial-2.html
@@ -276,8 +276,7 @@ gittutorial-2(7) Manual Page
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
-<p>You should work through <a href="gittutorial.html">gittutorial(7)</a>[A tutorial introduction to
-git] before reading this tutorial.</p>
+<p>You should work through <a href="gittutorial.html">gittutorial(7)</a> before reading this tutorial.</p>
 <p>The goal of this tutorial is to introduce two fundamental pieces of
 git's architecture--the object database and the index file--and to
 provide the reader with everything necessary to understand the rest
@@ -313,7 +312,7 @@ that would change the object's name as well).</p>
 following the example above generates a different SHA1 hash than
 the one shown above because the commit object records the time when
 it was created and the name of the person performing the commit.</p>
-<p>We can ask git about this particular object with the cat-file
+<p>We can ask git about this particular object with the <tt>cat-file</tt>
 command. Don't copy the 40 hex digits from this example but use those
 from your own version. Note that you can shorten it to only a few
 characters to save yourself typing all 40 hex digits:</p>
@@ -475,8 +474,8 @@ designate such an argument.</p>
 </div>
 <h2>The index file</h2>
 <div class="sectionbody">
-<p>The primary tool we've been using to create commits is "git commit
--a", which creates a commit including every change you've made to
+<p>The primary tool we've been using to create commits is <tt>git-commit
+-a</tt>, which creates a commit including every change you've made to
 your working tree.  But what if you want to commit changes only to
 certain files?  Or only certain changes to certain files?</p>
 <p>If we look at the way commits are created under the cover, we'll see
@@ -513,7 +512,7 @@ index a042389..513feba 100644
  hello world!
 +hello world, again</tt></pre>
 </div></div>
-<p>So "git diff" is comparing against something other than the head.
+<p>So <tt>git-diff</tt> is comparing against something other than the head.
 The thing that it's comparing against is actually the index file,
 which is stored in .git/index in a binary format, but whose contents
 we can examine with ls-files:</p>
@@ -527,9 +526,9 @@ $ git cat-file blob 513feba2
 hello world!
 hello world, again</tt></pre>
 </div></div>
-<p>So what our "git add" did was store a new blob and then put
+<p>So what our <tt>git-add</tt> did was store a new blob and then put
 a reference to it in the index file.  If we modify the file again,
-we'll see that the new modifications are reflected in the "git diff"
+we'll see that the new modifications are reflected in the <tt>git-diff</tt>
 output:</p>
 <div class="listingblock">
 <div class="content">
@@ -543,7 +542,7 @@ index 513feba..ba3da7b 100644
  hello world, again
 +again?</tt></pre>
 </div></div>
-<p>With the right arguments, git diff can also show us the difference
+<p>With the right arguments, <tt>git-diff</tt> can also show us the difference
 between the working directory and the last commit, or between the
 index and the last commit:</p>
 <div class="listingblock">
@@ -566,8 +565,8 @@ index a042389..513feba 100644
  hello world!
 +hello world, again</tt></pre>
 </div></div>
-<p>At any time, we can create a new commit using "git commit" (without
-the -a option), and verify that the state committed only includes the
+<p>At any time, we can create a new commit using <tt>git-commit</tt> (without
+the "-a" option), and verify that the state committed only includes the
 changes stored in the index file, not the additional change that is
 still only in our working tree:</p>
 <div class="listingblock">
@@ -583,17 +582,17 @@ index 513feba..ba3da7b 100644
  hello world, again
 +again?</tt></pre>
 </div></div>
-<p>So by default "git commit" uses the index to create the commit, not
-the working tree; the -a option to commit tells it to first update
+<p>So by default <tt>git-commit</tt> uses the index to create the commit, not
+the working tree; the "-a" option to commit tells it to first update
 the index with all changes in the working tree.</p>
-<p>Finally, it's worth looking at the effect of "git add" on the index
+<p>Finally, it's worth looking at the effect of <tt>git-add</tt> on the index
 file:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ echo "goodbye, world" &gt;closing.txt
 $ git add closing.txt</tt></pre>
 </div></div>
-<p>The effect of the "git add" was to add one entry to the index file:</p>
+<p>The effect of the <tt>git-add</tt> was to add one entry to the index file:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git ls-files --stage
@@ -630,13 +629,13 @@ changes in the working directory that aren't reflected in the index,
 it is marked "changed but not updated".  At this point, running "git
 commit" would create a commit that added closing.txt (with its new
 contents), but that didn't modify file.txt.</p>
-<p>Also, note that a bare "git diff" shows the changes to file.txt, but
+<p>Also, note that a bare <tt>git diff</tt> shows the changes to file.txt, but
 not the addition of closing.txt, because the version of closing.txt
 in the index file is identical to the one in the working directory.</p>
 <p>In addition to being the staging area for new commits, the index file
 is also populated from the object database when checking out a
 branch, and is used to hold the trees involved in a merge operation.
-See the <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>[core tutorial] and the relevant man
+See <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a> and the relevant man
 pages for details.</p>
 </div>
 <h2>What next?</h2>
@@ -644,16 +643,15 @@ pages for details.</p>
 <p>At this point you should know everything necessary to read the man
 pages for any of the git commands; one good place to start would be
 with the commands mentioned in <a href="everyday.html">Everyday git</a>.  You
-should be able to find any unknown jargon in the
-<a href="gitglossary.html">gitglossary(7)</a>[Glossary].</p>
+should be able to find any unknown jargon in <a href="gitglossary.html">gitglossary(7)</a>.</p>
 <p>The <a href="user-manual.html">Git User's Manual</a> provides a more
 comprehensive introduction to git.</p>
-<p>The <a href="gitcvs-migration.html">gitcvs-migration(7)</a>[CVS migration] document explains how to
+<p><a href="gitcvs-migration.html">gitcvs-migration(7)</a> explains how to
 import a CVS repository into git, and shows how to use git in a
 CVS-like way.</p>
 <p>For some interesting examples of git use, see the
 <a href="howto-index.html">howtos</a>.</p>
-<p>For git developers, the <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>[Core tutorial] goes
+<p>For git developers, <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a> goes
 into detail on the lower-level git mechanisms involved in, for
 example, creating a new commit.</p>
 </div>
@@ -672,7 +670,7 @@ example, creating a new commit.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 27-Jun-2008 08:26:24 UTC
+Last updated 02-Jul-2008 03:02:11 UTC
 </div>
 </div>
 </body>
diff --git a/gittutorial-2.txt b/gittutorial-2.txt
index 31e8a23a4..6c93445cc 100644
--- a/gittutorial-2.txt
+++ b/gittutorial-2.txt
@@ -12,8 +12,7 @@ git *
 DESCRIPTION
 -----------
 
-You should work through linkgit:gittutorial[7][A tutorial introduction to
-git] before reading this tutorial.
+You should work through linkgit:gittutorial[7] before reading this tutorial.
 
 The goal of this tutorial is to introduce two fundamental pieces of
 git's architecture--the object database and the index file--and to
@@ -55,7 +54,7 @@ following the example above generates a different SHA1 hash than
 the one shown above because the commit object records the time when
 it was created and the name of the person performing the commit.
 
-We can ask git about this particular object with the cat-file
+We can ask git about this particular object with the `cat-file`
 command. Don't copy the 40 hex digits from this example but use those
 from your own version. Note that you can shorten it to only a few
 characters to save yourself typing all 40 hex digits:
@@ -213,8 +212,8 @@ designate such an argument.
 The index file
 --------------
 
-The primary tool we've been using to create commits is "git commit
--a", which creates a commit including every change you've made to
+The primary tool we've been using to create commits is `git-commit
+-a`, which creates a commit including every change you've made to
 your working tree.  But what if you want to commit changes only to
 certain files?  Or only certain changes to certain files?
 
@@ -256,7 +255,7 @@ index a042389..513feba 100644
 +hello world, again
 ------------------------------------------------
 
-So "git diff" is comparing against something other than the head.
+So `git-diff` is comparing against something other than the head.
 The thing that it's comparing against is actually the index file,
 which is stored in .git/index in a binary format, but whose contents
 we can examine with ls-files:
@@ -271,9 +270,9 @@ hello world!
 hello world, again
 ------------------------------------------------
 
-So what our "git add" did was store a new blob and then put
+So what our `git-add` did was store a new blob and then put
 a reference to it in the index file.  If we modify the file again,
-we'll see that the new modifications are reflected in the "git diff"
+we'll see that the new modifications are reflected in the `git-diff`
 output:
 
 ------------------------------------------------
@@ -288,7 +287,7 @@ index 513feba..ba3da7b 100644
 +again?
 ------------------------------------------------
 
-With the right arguments, git diff can also show us the difference
+With the right arguments, `git-diff` can also show us the difference
 between the working directory and the last commit, or between the
 index and the last commit:
 
@@ -312,8 +311,8 @@ index a042389..513feba 100644
 +hello world, again
 ------------------------------------------------
 
-At any time, we can create a new commit using "git commit" (without
-the -a option), and verify that the state committed only includes the
+At any time, we can create a new commit using `git-commit` (without
+the "-a" option), and verify that the state committed only includes the
 changes stored in the index file, not the additional change that is
 still only in our working tree:
 
@@ -330,11 +329,11 @@ index 513feba..ba3da7b 100644
 +again?
 ------------------------------------------------
 
-So by default "git commit" uses the index to create the commit, not
-the working tree; the -a option to commit tells it to first update
+So by default `git-commit` uses the index to create the commit, not
+the working tree; the "-a" option to commit tells it to first update
 the index with all changes in the working tree.
 
-Finally, it's worth looking at the effect of "git add" on the index
+Finally, it's worth looking at the effect of `git-add` on the index
 file:
 
 ------------------------------------------------
@@ -342,7 +341,7 @@ $ echo "goodbye, world" >closing.txt
 $ git add closing.txt
 ------------------------------------------------
 
-The effect of the "git add" was to add one entry to the index file:
+The effect of the `git-add` was to add one entry to the index file:
 
 ------------------------------------------------
 $ git ls-files --stage
@@ -383,14 +382,14 @@ it is marked "changed but not updated".  At this point, running "git
 commit" would create a commit that added closing.txt (with its new
 contents), but that didn't modify file.txt.
 
-Also, note that a bare "git diff" shows the changes to file.txt, but
+Also, note that a bare `git diff` shows the changes to file.txt, but
 not the addition of closing.txt, because the version of closing.txt
 in the index file is identical to the one in the working directory.
 
 In addition to being the staging area for new commits, the index file
 is also populated from the object database when checking out a
 branch, and is used to hold the trees involved in a merge operation.
-See the linkgit:gitcore-tutorial[7][core tutorial] and the relevant man
+See linkgit:gitcore-tutorial[7] and the relevant man
 pages for details.
 
 What next?
@@ -399,20 +398,19 @@ What next?
 At this point you should know everything necessary to read the man
 pages for any of the git commands; one good place to start would be
 with the commands mentioned in link:everyday.html[Everyday git].  You
-should be able to find any unknown jargon in the
-linkgit:gitglossary[7][Glossary].
+should be able to find any unknown jargon in linkgit:gitglossary[7].
 
 The link:user-manual.html[Git User's Manual] provides a more
 comprehensive introduction to git.
 
-The linkgit:gitcvs-migration[7][CVS migration] document explains how to
+linkgit:gitcvs-migration[7] explains how to
 import a CVS repository into git, and shows how to use git in a
 CVS-like way.
 
 For some interesting examples of git use, see the
 link:howto-index.html[howtos].
 
-For git developers, the linkgit:gitcore-tutorial[7][Core tutorial] goes
+For git developers, linkgit:gitcore-tutorial[7] goes
 into detail on the lower-level git mechanisms involved in, for
 example, creating a new commit.
 
diff --git a/gittutorial.html b/gittutorial.html
index 7bc31e321..eddcf15b9 100644
--- a/gittutorial.html
+++ b/gittutorial.html
@@ -281,11 +281,11 @@ changes to it, and share changes with other developers.</p>
 <p>If you are instead primarily interested in using git to fetch a project,
 for example, to test the latest version, you may prefer to start with
 the first two chapters of <a href="user-manual.html">The Git User's Manual</a>.</p>
-<p>First, note that you can get documentation for a command such as "git
-diff" with:</p>
+<p>First, note that you can get documentation for a command such as
+<tt>git log --graph</tt> with:</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ man git-diff</tt></pre>
+<pre><tt>$ man git-log</tt></pre>
 </div></div>
 <p>It is a good idea to introduce yourself to git with your name and
 public email address before doing any operation.  The easiest
@@ -314,14 +314,14 @@ $ git init</tt></pre>
 <p>You've now initialized the working directory--you may notice a new
 directory created, named ".git".</p>
 <p>Next, tell git to take a snapshot of the contents of all files under the
-current directory (note the <em>.</em>), with <a href="git-add.html">git-add(1)</a>:</p>
+current directory (note the <em>.</em>), with <tt>git-add</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git add .</tt></pre>
 </div></div>
 <p>This snapshot is now stored in a temporary staging area which git calls
 the "index".  You can permanently store the contents of the index in the
-repository with <a href="git-commit.html">git-commit(1)</a>:</p>
+repository with <tt>git-commit</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git commit</tt></pre>
@@ -337,14 +337,14 @@ version of your project in git.</p>
 <pre><tt>$ git add file1 file2 file3</tt></pre>
 </div></div>
 <p>You are now ready to commit.  You can see what is about to be committed
-using <a href="git-diff.html">git-diff(1)</a> with the --cached option:</p>
+using <tt>git-diff</tt> with the --cached option:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git diff --cached</tt></pre>
 </div></div>
-<p>(Without --cached, <a href="git-diff.html">git-diff(1)</a> will show you any changes that
+<p>(Without --cached, <tt>git-diff</tt> will show you any changes that
 you've made but not yet added to the index.)  You can also get a brief
-summary of the situation with <a href="git-status.html">git-status(1)</a>:</p>
+summary of the situation with <tt>git-status</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git status
@@ -365,7 +365,7 @@ newly modified content to the index.  Finally, commit your changes with:</p>
 </div></div>
 <p>This will again prompt you for a message describing the change, and then
 record a new version of the project.</p>
-<p>Alternatively, instead of running <tt>git add</tt> beforehand, you can use</p>
+<p>Alternatively, instead of running <tt>git-add</tt> beforehand, you can use</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git commit -a</tt></pre>
@@ -381,9 +381,9 @@ commit in the body.</p>
 </div>
 <h2>Git tracks content not files</h2>
 <div class="sectionbody">
-<p>Many revision control systems provide an "add" command that tells the
-system to start tracking changes to a new file.  Git's "add" command
-does something simpler and more powerful: <tt>git add</tt> is used both for new
+<p>Many revision control systems provide an <tt>add</tt> command that tells the
+system to start tracking changes to a new file.  Git's <tt>add</tt> command
+does something simpler and more powerful: <tt>git-add</tt> is used both for new
 and newly modified files, and in both cases it takes a snapshot of the
 given files and stages that content in the index, ready for inclusion in
 the next commit.</p>
@@ -533,14 +533,14 @@ it easier:</p>
 <pre><tt>$ git remote add bob /home/bob/myrepo</tt></pre>
 </div></div>
 <p>With this, Alice can perform the first operation alone using the
-"git fetch" command without merging them with her own branch,
+<tt>git-fetch</tt> command without merging them with her own branch,
 using:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git fetch bob</tt></pre>
 </div></div>
 <p>Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with <tt>git remote</tt>, what was
+remote repository shorthand set up with <tt>git-remote</tt>, what was
 fetched is stored in a remote tracking branch, in this case
 <tt>bob/master</tt>.  So after this:</p>
 <div class="listingblock">
@@ -577,8 +577,8 @@ used for pulls:</p>
 <pre><tt>$ git config --get remote.origin.url
 /home/alice/project</tt></pre>
 </div></div>
-<p>(The complete configuration created by git-clone is visible using
-"git config -l", and the <a href="git-config.html">git-config(1)</a> man page
+<p>(The complete configuration created by <tt>git-clone</tt> is visible using
+<tt>git config -l</tt>, and the <a href="git-config.html">git-config(1)</a> man page
 explains the meaning of each option.)</p>
 <p>Git also keeps a pristine copy of Alice's master branch under the
 name "origin/master":</p>
@@ -597,12 +597,12 @@ perform clones and pulls using the ssh protocol:</p>
 see <a href="git-pull.html">git-pull(1)</a> for details.</p>
 <p>Git can also be used in a CVS-like mode, with a central repository
 that various users push changes to; see <a href="git-push.html">git-push(1)</a> and
-<a href="gitcvs-migration.html">gitcvs-migration(7)</a>[git for CVS users].</p>
+<a href="gitcvs-migration.html">gitcvs-migration(7)</a>.</p>
 </div>
 <h2>Exploring history</h2>
 <div class="sectionbody">
 <p>Git history is represented as a series of interrelated commits.  We
-have already seen that the git log command can list those commits.
+have already seen that the <tt>git-log</tt> command can list those commits.
 Note that first line of each git log entry also gives a name for the
 commit:</p>
 <div class="listingblock">
@@ -614,7 +614,7 @@ Date:   Tue May 16 17:18:22 2006 -0700
 
     merge-base: Clarify the comments on post processing.</tt></pre>
 </div></div>
-<p>We can give this name to git show to see the details about this
+<p>We can give this name to <tt>git-show</tt> to see the details about this
 commit.</p>
 <div class="listingblock">
 <div class="content">
@@ -646,7 +646,7 @@ $ git show HEAD^2 # show the second parent of HEAD</tt></pre>
 <p>You can also give commits names of your own; after running</p>
 <div class="listingblock">
 <div class="content">
-<pre><tt>$ git-tag v2.5 1b2e1d63ff</tt></pre>
+<pre><tt>$ git tag v2.5 1b2e1d63ff</tt></pre>
 </div></div>
 <p>you can refer to 1b2e1d63ff by the name "v2.5".  If you intend to
 share this name with other people (for example, to identify a release
@@ -665,19 +665,19 @@ $ git reset --hard HEAD^ # reset your current branch and working
 <p>Be careful with that last command: in addition to losing any changes
 in the working directory, it will also remove all later commits from
 this branch.  If this branch is the only branch containing those
-commits, they will be lost.  Also, don't use "git reset" on a
+commits, they will be lost.  Also, don't use <tt>git-reset</tt> on a
 publicly-visible branch that other developers pull from, as it will
 force needless merges on other developers to clean up the history.
-If you need to undo changes that you have pushed, use <a href="git-revert.html">git-revert(1)</a>
+If you need to undo changes that you have pushed, use <tt>git-revert</tt>
 instead.</p>
-<p>The git grep command can search for strings in any version of your
+<p>The <tt>git-grep</tt> command can search for strings in any version of your
 project, so</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git grep "hello" v2.5</tt></pre>
 </div></div>
 <p>searches for all occurrences of "hello" in v2.5.</p>
-<p>If you leave out the commit name, git grep will search any of the
+<p>If you leave out the commit name, <tt>git-grep</tt> will search any of the
 files it manages in your current directory.  So</p>
 <div class="listingblock">
 <div class="content">
@@ -685,7 +685,7 @@ files it manages in your current directory.  So</p>
 </div></div>
 <p>is a quick way to search just the files that are tracked by git.</p>
 <p>Many git commands also take sets of commits, which can be specified
-in a number of ways.  Here are some examples with git log:</p>
+in a number of ways.  Here are some examples with <tt>git-log</tt>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git log v2.5..v2.6            # commits between v2.5 and v2.6
@@ -694,7 +694,7 @@ $ git log --since="2 weeks ago" # commits from the last 2 weeks
 $ git log v2.5.. Makefile       # commits since v2.5 which modify
                                 # Makefile</tt></pre>
 </div></div>
-<p>You can also give git log a "range" of commits where the first is not
+<p>You can also give <tt>git-log</tt> a "range" of commits where the first is not
 necessarily an ancestor of the second; for example, if the tips of
 the branches "stable-release" and "master" diverged from a common
 commit some time ago, then</p>
@@ -710,12 +710,12 @@ stable branch, while</p>
 </div></div>
 <p>will show the list of commits made on the stable branch but not
 the experimental branch.</p>
-<p>The "git log" command has a weakness: it must present commits in a
+<p>The <tt>git-log</tt> command has a weakness: it must present commits in a
 list.  When the history has lines of development that diverged and
-then merged back together, the order in which "git log" presents
+then merged back together, the order in which <tt>git-log</tt> presents
 those commits is meaningless.</p>
 <p>Most projects with multiple contributors (such as the linux kernel,
-or git itself) have frequent merges, and gitk does a better job of
+or git itself) have frequent merges, and <tt>gitk</tt> does a better job of
 visualizing their history.  For example,</p>
 <div class="listingblock">
 <div class="content">
@@ -732,7 +732,7 @@ of the file:</p>
 <div class="content">
 <pre><tt>$ git diff v2.5:Makefile HEAD:Makefile.in</tt></pre>
 </div></div>
-<p>You can also use "git show" to see any such file:</p>
+<p>You can also use <tt>git-show</tt> to see any such file:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git show v2.5:Makefile</tt></pre>
@@ -760,9 +760,9 @@ The index file is a cache of the state of a directory tree,
 </p>
 </li>
 </ul>
-<p><a href="gittutorial-2.html">gittutorial-2(7)</a>[Part two of this tutorial] explains the object
+<p>Part two of this tutorial explains the object
 database, the index file, and a few other odds and ends that you'll
-need to make the most of git.</p>
+need to make the most of git. You can find it at <a href="gittutorial-2.html">gittutorial-2(7)</a>.</p>
 <p>If you don't want to continue with that right away, a few other
 digressions that may be interesting at this point are:</p>
 <ul>
@@ -791,7 +791,7 @@ digressions that may be interesting at this point are:</p>
 </li>
 <li>
 <p>
-<a href="gitcvs-migration.html">gitcvs-migration(7)</a>[git for CVS users].
+<a href="gitcvs-migration.html">gitcvs-migration(7)</a>: Git for CVS users.
 </p>
 </li>
 </ul>
@@ -811,7 +811,7 @@ digressions that may be interesting at this point are:</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 13-Jun-2008 10:02:46 UTC
+Last updated 02-Jul-2008 03:02:11 UTC
 </div>
 </div>
 </body>
diff --git a/gittutorial.txt b/gittutorial.txt
index d465aab64..036a27c41 100644
--- a/gittutorial.txt
+++ b/gittutorial.txt
@@ -19,11 +19,11 @@ If you are instead primarily interested in using git to fetch a project,
 for example, to test the latest version, you may prefer to start with
 the first two chapters of link:user-manual.html[The Git User's Manual].
 
-First, note that you can get documentation for a command such as "git
-diff" with:
+First, note that you can get documentation for a command such as
+`git log --graph` with:
 
 ------------------------------------------------
-$ man git-diff
+$ man git-log
 ------------------------------------------------
 
 It is a good idea to introduce yourself to git with your name and
@@ -58,7 +58,7 @@ You've now initialized the working directory--you may notice a new
 directory created, named ".git".
 
 Next, tell git to take a snapshot of the contents of all files under the
-current directory (note the '.'), with linkgit:git-add[1]:
+current directory (note the '.'), with `git-add`:
 
 ------------------------------------------------
 $ git add .
@@ -66,7 +66,7 @@ $ git add .
 
 This snapshot is now stored in a temporary staging area which git calls
 the "index".  You can permanently store the contents of the index in the
-repository with linkgit:git-commit[1]:
+repository with `git-commit`:
 
 ------------------------------------------------
 $ git commit
@@ -85,15 +85,15 @@ $ git add file1 file2 file3
 ------------------------------------------------
 
 You are now ready to commit.  You can see what is about to be committed
-using linkgit:git-diff[1] with the --cached option:
+using `git-diff` with the --cached option:
 
 ------------------------------------------------
 $ git diff --cached
 ------------------------------------------------
 
-(Without --cached, linkgit:git-diff[1] will show you any changes that
+(Without --cached, `git-diff` will show you any changes that
 you've made but not yet added to the index.)  You can also get a brief
-summary of the situation with linkgit:git-status[1]:
+summary of the situation with `git-status`:
 
 ------------------------------------------------
 $ git status
@@ -117,7 +117,7 @@ $ git commit
 This will again prompt you for a message describing the change, and then
 record a new version of the project.
 
-Alternatively, instead of running `git add` beforehand, you can use
+Alternatively, instead of running `git-add` beforehand, you can use
 
 ------------------------------------------------
 $ git commit -a
@@ -136,9 +136,9 @@ commit in the body.
 Git tracks content not files
 ----------------------------
 
-Many revision control systems provide an "add" command that tells the
-system to start tracking changes to a new file.  Git's "add" command
-does something simpler and more powerful: `git add` is used both for new
+Many revision control systems provide an `add` command that tells the
+system to start tracking changes to a new file.  Git's `add` command
+does something simpler and more powerful: `git-add` is used both for new
 and newly modified files, and in both cases it takes a snapshot of the
 given files and stages that content in the index, ready for inclusion in
 the next commit.
@@ -316,7 +316,7 @@ $ git remote add bob /home/bob/myrepo
 ------------------------------------------------
 
 With this, Alice can perform the first operation alone using the
-"git fetch" command without merging them with her own branch,
+`git-fetch` command without merging them with her own branch,
 using:
 
 -------------------------------------
@@ -324,7 +324,7 @@ $ git fetch bob
 -------------------------------------
 
 Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with `git remote`, what was
+remote repository shorthand set up with `git-remote`, what was
 fetched is stored in a remote tracking branch, in this case
 `bob/master`.  So after this:
 
@@ -368,8 +368,8 @@ $ git config --get remote.origin.url
 /home/alice/project
 -------------------------------------
 
-(The complete configuration created by git-clone is visible using
-"git config -l", and the linkgit:git-config[1] man page
+(The complete configuration created by `git-clone` is visible using
+`git config -l`, and the linkgit:git-config[1] man page
 explains the meaning of each option.)
 
 Git also keeps a pristine copy of Alice's master branch under the
@@ -392,13 +392,13 @@ see linkgit:git-pull[1] for details.
 
 Git can also be used in a CVS-like mode, with a central repository
 that various users push changes to; see linkgit:git-push[1] and
-linkgit:gitcvs-migration[7][git for CVS users].
+linkgit:gitcvs-migration[7].
 
 Exploring history
 -----------------
 
 Git history is represented as a series of interrelated commits.  We
-have already seen that the git log command can list those commits.
+have already seen that the `git-log` command can list those commits.
 Note that first line of each git log entry also gives a name for the
 commit:
 
@@ -411,7 +411,7 @@ Date:   Tue May 16 17:18:22 2006 -0700
     merge-base: Clarify the comments on post processing.
 -------------------------------------
 
-We can give this name to git show to see the details about this
+We can give this name to `git-show` to see the details about this
 commit.
 
 -------------------------------------
@@ -447,7 +447,7 @@ $ git show HEAD^2 # show the second parent of HEAD
 You can also give commits names of your own; after running
 
 -------------------------------------
-$ git-tag v2.5 1b2e1d63ff
+$ git tag v2.5 1b2e1d63ff
 -------------------------------------
 
 you can refer to 1b2e1d63ff by the name "v2.5".  If you intend to
@@ -469,13 +469,13 @@ $ git reset --hard HEAD^ # reset your current branch and working
 Be careful with that last command: in addition to losing any changes
 in the working directory, it will also remove all later commits from
 this branch.  If this branch is the only branch containing those
-commits, they will be lost.  Also, don't use "git reset" on a
+commits, they will be lost.  Also, don't use `git-reset` on a
 publicly-visible branch that other developers pull from, as it will
 force needless merges on other developers to clean up the history.
-If you need to undo changes that you have pushed, use linkgit:git-revert[1]
+If you need to undo changes that you have pushed, use `git-revert`
 instead.
 
-The git grep command can search for strings in any version of your
+The `git-grep` command can search for strings in any version of your
 project, so
 
 -------------------------------------
@@ -484,7 +484,7 @@ $ git grep "hello" v2.5
 
 searches for all occurrences of "hello" in v2.5.
 
-If you leave out the commit name, git grep will search any of the
+If you leave out the commit name, `git-grep` will search any of the
 files it manages in your current directory.  So
 
 -------------------------------------
@@ -494,7 +494,7 @@ $ git grep "hello"
 is a quick way to search just the files that are tracked by git.
 
 Many git commands also take sets of commits, which can be specified
-in a number of ways.  Here are some examples with git log:
+in a number of ways.  Here are some examples with `git-log`:
 
 -------------------------------------
 $ git log v2.5..v2.6            # commits between v2.5 and v2.6
@@ -504,7 +504,7 @@ $ git log v2.5.. Makefile       # commits since v2.5 which modify
 				# Makefile
 -------------------------------------
 
-You can also give git log a "range" of commits where the first is not
+You can also give `git-log` a "range" of commits where the first is not
 necessarily an ancestor of the second; for example, if the tips of
 the branches "stable-release" and "master" diverged from a common
 commit some time ago, then
@@ -523,13 +523,13 @@ $ git log experimental..stable
 will show the list of commits made on the stable branch but not
 the experimental branch.
 
-The "git log" command has a weakness: it must present commits in a
+The `git-log` command has a weakness: it must present commits in a
 list.  When the history has lines of development that diverged and
-then merged back together, the order in which "git log" presents
+then merged back together, the order in which `git-log` presents
 those commits is meaningless.
 
 Most projects with multiple contributors (such as the linux kernel,
-or git itself) have frequent merges, and gitk does a better job of
+or git itself) have frequent merges, and `gitk` does a better job of
 visualizing their history.  For example,
 
 -------------------------------------
@@ -549,7 +549,7 @@ of the file:
 $ git diff v2.5:Makefile HEAD:Makefile.in
 -------------------------------------
 
-You can also use "git show" to see any such file:
+You can also use `git-show` to see any such file:
 
 -------------------------------------
 $ git show v2.5:Makefile
@@ -571,9 +571,9 @@ is based:
     used to create commits, check out working directories, and
     hold the various trees involved in a merge.
 
-linkgit:gittutorial-2[7][Part two of this tutorial] explains the object
+Part two of this tutorial explains the object
 database, the index file, and a few other odds and ends that you'll
-need to make the most of git.
+need to make the most of git. You can find it at linkgit:gittutorial-2[7].
 
 If you don't want to continue with that right away, a few other
 digressions that may be interesting at this point are:
@@ -592,7 +592,7 @@ digressions that may be interesting at this point are:
 
   * link:everyday.html[Everyday GIT with 20 Commands Or So]
 
-  * linkgit:gitcvs-migration[7][git for CVS users].
+  * linkgit:gitcvs-migration[7]: Git for CVS users.
 
 SEE ALSO
 --------
diff --git a/howto-index.html b/howto-index.html
index 42efce14d..8eedd2671 100644
--- a/howto-index.html
+++ b/howto-index.html
@@ -368,7 +368,7 @@ strategy.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 26-Jun-2008 06:33:16 UTC
+Last updated 02-Jul-2008 03:02:14 UTC
 </div>
 </div>
 </body>
diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html
index c71878a16..3f9d89538 100644
--- a/howto/revert-branch-rebase.html
+++ b/howto/revert-branch-rebase.html
@@ -434,7 +434,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:36 UTC
+Last updated 02-Jul-2008 03:02:15 UTC
 </div>
 </div>
 </body>
diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html
index eb7bcab03..1d99920a4 100644
--- a/howto/using-merge-subtree.html
+++ b/howto/using-merge-subtree.html
@@ -365,7 +365,7 @@ Please note that if the other project merges from you, then it will
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:36 UTC
+Last updated 02-Jul-2008 03:02:15 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-allocation-growing.html b/technical/api-allocation-growing.html
index b577d8d4a..208153f13 100644
--- a/technical/api-allocation-growing.html
+++ b/technical/api-allocation-growing.html
@@ -306,7 +306,7 @@ ary[nr++] = value you like;</tt></pre>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:37 UTC
+Last updated 02-Jul-2008 03:02:16 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-builtin.html b/technical/api-builtin.html
index db0584b30..ca82b85d2 100644
--- a/technical/api-builtin.html
+++ b/technical/api-builtin.html
@@ -365,7 +365,7 @@ command.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:38 UTC
+Last updated 02-Jul-2008 03:02:16 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-decorate.html b/technical/api-decorate.html
index e780b92bd..302a96969 100644
--- a/technical/api-decorate.html
+++ b/technical/api-decorate.html
@@ -269,7 +269,7 @@ div.exampleblock-content {
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:38 UTC
+Last updated 02-Jul-2008 03:02:17 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-diff.html b/technical/api-diff.html
index 7b03996cb..72edeeed8 100644
--- a/technical/api-diff.html
+++ b/technical/api-diff.html
@@ -582,7 +582,7 @@ RECURSIVE, TREE_IN_RECURSIVE
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:39 UTC
+Last updated 02-Jul-2008 03:02:17 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-directory-listing.html b/technical/api-directory-listing.html
index 7d7708b6c..439d78edd 100644
--- a/technical/api-directory-listing.html
+++ b/technical/api-directory-listing.html
@@ -393,7 +393,7 @@ Use <tt>dir.entries[]</tt>.
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:40 UTC
+Last updated 02-Jul-2008 03:02:17 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-gitattributes.html b/technical/api-gitattributes.html
index 16a97fd4f..23a1c433a 100644
--- a/technical/api-gitattributes.html
+++ b/technical/api-gitattributes.html
@@ -417,7 +417,7 @@ Act on <tt>.value</tt> member of the result, left in <tt>check[]</tt>:
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:40 UTC
+Last updated 02-Jul-2008 03:02:18 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-grep.html b/technical/api-grep.html
index 60fcd8203..a92769d09 100644
--- a/technical/api-grep.html
+++ b/technical/api-grep.html
@@ -276,7 +276,7 @@ grep_buffer()
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:41 UTC
+Last updated 02-Jul-2008 03:02:18 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-hash.html b/technical/api-hash.html
index 5bb36d065..f7eee356b 100644
--- a/technical/api-hash.html
+++ b/technical/api-hash.html
@@ -269,7 +269,7 @@ div.exampleblock-content {
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:42 UTC
+Last updated 02-Jul-2008 03:02:18 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-history-graph.html b/technical/api-history-graph.html
index 6a99aa1ac..e13c691d8 100644
--- a/technical/api-history-graph.html
+++ b/technical/api-history-graph.html
@@ -501,7 +501,7 @@ M-. \ \
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:42 UTC
+Last updated 02-Jul-2008 03:02:19 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-in-core-index.html b/technical/api-in-core-index.html
index 5499567dc..d9558cca1 100644
--- a/technical/api-in-core-index.html
+++ b/technical/api-in-core-index.html
@@ -337,7 +337,7 @@ cache_tree_update()
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:43 UTC
+Last updated 02-Jul-2008 03:02:19 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-index.html b/technical/api-index.html
index 66d6fe48a..908710886 100644
--- a/technical/api-index.html
+++ b/technical/api-index.html
@@ -382,7 +382,7 @@ documents them.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:53 UTC
+Last updated 02-Jul-2008 03:02:23 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-lockfile.html b/technical/api-lockfile.html
index c3d3a72da..ab222b76a 100644
--- a/technical/api-lockfile.html
+++ b/technical/api-lockfile.html
@@ -361,7 +361,7 @@ that unrelated file descriptor.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:43 UTC
+Last updated 02-Jul-2008 03:02:19 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-object-access.html b/technical/api-object-access.html
index e7a231435..e26960768 100644
--- a/technical/api-object-access.html
+++ b/technical/api-object-access.html
@@ -311,7 +311,7 @@ Use of object flags
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:44 UTC
+Last updated 02-Jul-2008 03:02:20 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html
index d075c0542..da2d3402e 100644
--- a/technical/api-parse-options.html
+++ b/technical/api-parse-options.html
@@ -618,7 +618,7 @@ for real-world examples.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 23-Jun-2008 07:13:38 UTC
+Last updated 02-Jul-2008 03:02:20 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-path-list.html b/technical/api-path-list.html
index 0588311ee..c569f88ad 100644
--- a/technical/api-path-list.html
+++ b/technical/api-path-list.html
@@ -484,7 +484,7 @@ Setting the <tt>strdup_paths</tt> member to 1 will strdup() the strings
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 18-Jun-2008 03:17:08 UTC
+Last updated 02-Jul-2008 03:02:21 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-quote.html b/technical/api-quote.html
index 6fe5b0739..b9d6fabd9 100644
--- a/technical/api-quote.html
+++ b/technical/api-quote.html
@@ -286,7 +286,7 @@ quoting for foreign languages
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:46 UTC
+Last updated 02-Jul-2008 03:02:21 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-remote.html b/technical/api-remote.html
index 58f93c585..a33256a41 100644
--- a/technical/api-remote.html
+++ b/technical/api-remote.html
@@ -436,7 +436,7 @@ process of interacting with remotes.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:47 UTC
+Last updated 02-Jul-2008 03:02:21 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-revision-walking.html b/technical/api-revision-walking.html
index 824760fd3..a45091354 100644
--- a/technical/api-revision-walking.html
+++ b/technical/api-revision-walking.html
@@ -365,7 +365,7 @@ remaining functions;
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:47 UTC
+Last updated 02-Jul-2008 03:02:22 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-run-command.html b/technical/api-run-command.html
index 608967942..f4f555500 100644
--- a/technical/api-run-command.html
+++ b/technical/api-run-command.html
@@ -564,7 +564,7 @@ It must not change the program's state that the caller of the
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 18-Jun-2008 03:17:08 UTC
+Last updated 02-Jul-2008 03:02:22 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-setup.html b/technical/api-setup.html
index 4a461996c..78475cb21 100644
--- a/technical/api-setup.html
+++ b/technical/api-setup.html
@@ -301,7 +301,7 @@ get_pathspec()
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:48 UTC
+Last updated 02-Jul-2008 03:02:22 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-strbuf.html b/technical/api-strbuf.html
index 6ad5e5ecd..1bcc8958b 100644
--- a/technical/api-strbuf.html
+++ b/technical/api-strbuf.html
@@ -681,7 +681,7 @@ same behaviour as well.</td>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:48 UTC
+Last updated 02-Jul-2008 03:02:22 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-tree-walking.html b/technical/api-tree-walking.html
index 228a66f7d..3b4d51c3a 100644
--- a/technical/api-tree-walking.html
+++ b/technical/api-tree-walking.html
@@ -296,7 +296,7 @@ get_tree_entry
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:49 UTC
+Last updated 02-Jul-2008 03:02:22 UTC
 </div>
 </div>
 </body>
diff --git a/technical/api-xdiff-interface.html b/technical/api-xdiff-interface.html
index 677d214ea..bcb0c87c5 100644
--- a/technical/api-xdiff-interface.html
+++ b/technical/api-xdiff-interface.html
@@ -270,7 +270,7 @@ xdiff_emit_consume_fn.</p>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 08-Jun-2008 01:34:49 UTC
+Last updated 02-Jul-2008 03:02:23 UTC
 </div>
 </div>
 </body>
diff --git a/user-manual.html b/user-manual.html
index 0116b844e..3c8d094be 100644
--- a/user-manual.html
+++ b/user-manual.html
@@ -1,12 +1,12 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id280264">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -&gt; index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -&gt; object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -&gt; index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -&gt; working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git-fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git-pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git-fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id280263">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -&gt; index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -&gt; object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -&gt; index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -&gt; working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
 command-line skills, but no previous knowledge of git.</p><p><a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a href="#exploring-git-history" title="Chapter 2. Exploring git history">Chapter 2, <i>Exploring git history</i></a> explain how
 to fetch and study a project using git—read these chapters to learn how
 to build and test a particular version of a software project, search for
 regressions, and so on.</p><p>People needing to do actual development will also want to read
 <a href="#Developing-with-git" title="Chapter 3. Developing with git">Chapter 3, <i>Developing with git</i></a> and <a href="#sharing-development" title="Chapter 4. Sharing development with others">Chapter 4, <i>Sharing development with others</i></a>.</p><p>Further chapters cover more specialized topics.</p><p>Comprehensive reference documentation is available through the man
-pages.  For a command such as "git clone", just use</p><div class="literallayout"><p>$ man git-clone</p></div><p>See also <a href="#git-quick-start" title="Appendix A. Git Quick Reference">Appendix A, <i>Git Quick Reference</i></a> for a brief overview of git commands,
+pages.  For a command such as "git clone &lt;repo&gt;", just use</p><div class="literallayout"><p>$ man git-clone</p></div><p>See also <a href="#git-quick-start" title="Appendix A. Git Quick Reference">Appendix A, <i>Git Quick Reference</i></a> for a brief overview of git commands,
 without any explanation.</p><p>Finally, see <a href="#todo" title="Appendix B. Notes and todo list for this manual">Appendix B, <i>Notes and todo list for this manual</i></a> for ways that you can help make this manual more
-complete.</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repositories-and-branches"></a>Chapter 1. Repositories and Branches</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-get-a-git-repository"></a>How to get a git repository</h2></div></div></div><p>It will be useful to have a git repository to experiment with as you
+complete.</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repositories-and-branches"></a>Chapter 1. Repositories and Branches</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git-fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-get-a-git-repository"></a>How to get a git repository</h2></div></div></div><p>It will be useful to have a git repository to experiment with as you
 read this manual.</p><p>The best way to get one is by using the <a href="git-clone.html" target="_top">git-clone(1)</a> command to
 download a copy of an existing repository.  If you don't already have a
 project in mind, here are some interesting examples:</p><div class="literallayout"><p>        # git itself (approx. 10MB download):<br>
@@ -77,7 +77,7 @@ index 65898fa..b002dc6 100644<br>
 <br>
         if (mkdir(".git", 0755) &lt; 0) {</p></div><p>As you can see, a commit shows who made the latest change, what they
 did, and why.</p><p>Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA1 id", shown on the first line of the "git show" output.  You can usually
+"SHA1 id", shown on the first line of the "git-show" output.  You can usually
 refer to a commit by a shorter name, such as a tag or a branch name, but this
 longer name can also be useful.  Most importantly, it is a globally unique
 name for this commit: so if you tell somebody else the object name (for
@@ -202,7 +202,7 @@ to just using the name of that repository.  So, for example, "origin"
 is usually a shortcut for the HEAD branch in the repository "origin".</p><p>For the complete list of paths which git checks for references, and
 the order it uses to decide which to choose when there are multiple
 references with the same shorthand name, see the "SPECIFYING
-REVISIONS" section of <a href="git-rev-parse.html" target="_top">git-rev-parse(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Updating-a-repository-with-git-fetch"></a>Updating a repository with git fetch</h2></div></div></div><p>Eventually the developer cloned from will do additional work in her
+REVISIONS" section of <a href="git-rev-parse.html" target="_top">git-rev-parse(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Updating-a-repository-with-git-fetch"></a>Updating a repository with git-fetch</h2></div></div></div><p>Eventually the developer cloned from will do additional work in her
 repository, creating new commits and advancing the branches to point
 at the new commits.</p><p>The command "git fetch", with no arguments, will update all of the
 remote-tracking branches to the latest version found in her
@@ -212,7 +212,7 @@ cloned from, using <a href="git-remote.html" target="_top">git-remote(1)</a>:</p
 $ git fetch linux-nfs<br>
 * refs/remotes/linux-nfs/master: storing branch 'master' ...<br>
   commit: bf81b46</p></div><p>New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:</p><div class="literallayout"><p>$ git branch -r<br>
+that you gave "git-remote add", in this case linux-nfs:</p><div class="literallayout"><p>$ git branch -r<br>
 linux-nfs/master<br>
 origin/master</p></div><p>If you run "git fetch &lt;remote&gt;" later, the tracking branches for the
 named &lt;remote&gt; will be updated.</p><p>If you examine the file .git/config, you will see that git has added
@@ -417,7 +417,7 @@ special staging area called "the index."</p><p>At the beginning, the content of
 that of the HEAD.  The command "git diff —cached", which shows
 the difference between the HEAD and the index, should therefore
 produce no output at that point.</p><p>Modifying the index is easy:</p><p>To update the index with the new contents of a modified file, use</p><div class="literallayout"><p>$ git add path/to/file</p></div><p>To add the contents of a new file to the index, use</p><div class="literallayout"><p>$ git add path/to/file</p></div><p>To remove a file from the index and from the working tree,</p><div class="literallayout"><p>$ git rm path/to/file</p></div><p>After each step you can verify that</p><div class="literallayout"><p>$ git diff --cached</p></div><p>always shows the difference between the HEAD and the index file—this
-is what you'd commit if you created the commit now—and that</p><div class="literallayout"><p>$ git diff</p></div><p>shows the difference between the working tree and the index file.</p><p>Note that "git add" always adds just the current contents of a file
+is what you'd commit if you created the commit now—and that</p><div class="literallayout"><p>$ git diff</p></div><p>shows the difference between the working tree and the index file.</p><p>Note that "git-add" always adds just the current contents of a file
 to the index; further changes to the same file will be ignored unless
 you run git-add on the file again.</p><p>When you're ready, just run</p><div class="literallayout"><p>$ git commit</p></div><p>and git will prompt you for a commit message and then create the new
 commit.  Check to make sure it looks like what you expected with</p><div class="literallayout"><p>$ git show</p></div><p>As a special shortcut,</p><div class="literallayout"><p>$ git commit -a</p></div><p>will update the index with any files that you've modified or removed
@@ -440,7 +440,7 @@ the first line on the Subject line and the rest of the commit in the
 body.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ignoring-files"></a>Ignoring files</h2></div></div></div><p>A project will often generate files that you do <span class="emphasis"><em>not</em></span> want to track with git.
 This typically includes files generated by a build process or temporary
 backup files made by your editor. Of course, <span class="emphasis"><em>not</em></span> tracking files with git
-is just a matter of <span class="emphasis"><em>not</em></span> calling "<code class="literal">git add</code>" on them. But it quickly becomes
+is just a matter of <span class="emphasis"><em>not</em></span> calling "<code class="literal">git-add</code>" on them. But it quickly becomes
 annoying to have these untracked files lying around; e.g. they make
 "<code class="literal">git add .</code>" and "<code class="literal">git commit -a</code>" practically useless, and they keep
 showing up in the output of "<code class="literal">git status</code>".</p><p>You can tell git to ignore certain files by creating a file called .gitignore
@@ -582,7 +582,7 @@ that case.</p><p>It is also possible to replace commits further back in the hist
 this is an advanced topic to be left for
 <a href="#cleaning-up-history" title="Chapter 5. Rewriting history and maintaining patch series">another chapter</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="checkout-of-path"></a>Checking out an old version of a file</h3></div></div></div><p>In the process of undoing a previous bad change, you may find it
 useful to check out an older version of a particular file using
-<a href="git-checkout.html" target="_top">git-checkout(1)</a>.  We've used git checkout before to switch
+<a href="git-checkout.html" target="_top">git-checkout(1)</a>.  We've used git-checkout before to switch
 branches, but it has quite different behavior if it is given a path
 name: the command</p><div class="literallayout"><p>$ git checkout HEAD^ path/to/file</p></div><p>replaces path/to/file by the contents it had in the commit HEAD^, and
 also updates the index to match.  It does not change branches.</p><p>If you just want to look at an old version of the file, without
@@ -648,9 +648,9 @@ you get exactly the history reachable from that commit that is lost.
 "tip of the line" as being dangling, but there might be a whole deep
 and complex commit history that was dropped.)</p><p>If you decide you want the history back, you can always create a new
 reference pointing to it, for example, a new branch:</p><div class="literallayout"><p>$ git branch recovered-branch 7281251ddd</p></div><p>Other types of dangling objects (blobs and trees) are also possible, and
-dangling objects can arise in other situations.</p></div></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="sharing-development"></a>Chapter 4. Sharing development with others</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="getting-updates-with-git-pull"></a>Getting updates with git pull</h2></div></div></div><p>After you clone a repository and make a few changes of your own, you
+dangling objects can arise in other situations.</p></div></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="sharing-development"></a>Chapter 4. Sharing development with others</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git-pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="getting-updates-with-git-pull"></a>Getting updates with git-pull</h2></div></div></div><p>After you clone a repository and make a few changes of your own, you
 may wish to check the original repository for updates and merge them
-into your own work.</p><p>We have already seen <a href="#Updating-a-repository-with-git-fetch" title="Updating a repository with git fetch">how to keep remote tracking branches up to date</a> with <a href="git-fetch.html" target="_top">git-fetch(1)</a>,
+into your own work.</p><p>We have already seen <a href="#Updating-a-repository-with-git-fetch" title="Updating a repository with git-fetch">how to keep remote tracking branches up to date</a> with <a href="git-fetch.html" target="_top">git-fetch(1)</a>,
 and how to merge two branches.  So you can merge in changes from the
 original repository's master branch with:</p><div class="literallayout"><p>$ git fetch<br>
 $ git merge origin/master</p></div><p>However, the <a href="git-pull.html" target="_top">git-pull(1)</a> command provides a way to do this in
@@ -686,7 +686,7 @@ remaining patches from the mailbox.</p><p>The final result will be a series of c
 the original mailbox, with authorship and commit log message each
 taken from the message containing each patch.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="public-repositories"></a>Public git repositories</h2></div></div></div><p>Another way to submit changes to a project is to tell the maintainer
 of that project to pull the changes from your repository using
-<a href="git-pull.html" target="_top">git-pull(1)</a>.  In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git pull">Getting updates with git pull</a>" we described this as a way to get
+<a href="git-pull.html" target="_top">git-pull(1)</a>.  In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git-pull">Getting updates with git-pull</a>" we described this as a way to get
 updates from the "main" repository, but it works just as well in the
 other direction.</p><p>If you and the maintainer both have accounts on the same machine, then
 you can just pull changes from each other's repositories directly;
@@ -732,8 +732,7 @@ adjustments to give web clients some extra information they need:</p><div class=
 $ cd proj.git<br>
 $ git --bare update-server-info<br>
 $ chmod a+x hooks/post-update</p></div><p>(For an explanation of the last two lines, see
-<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a>, and the documentation
-<a href="githooks.html" target="_top">githooks(5)</a>[Hooks used by git].)</p><p>Advertise the URL of proj.git.  Anybody else should then be able to
+<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a> and <a href="githooks.html" target="_top">githooks(5)</a>.)</p><p>Advertise the URL of proj.git.  Anybody else should then be able to
 clone or pull from that URL, for example with a command line like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
 <a href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a>
 for a slightly more sophisticated setup using WebDAV which also
@@ -779,10 +778,10 @@ the right to push to the same repository.  In that case, the correct
 solution is to retry the push after first updating your work by either a
 pull or a fetch followed by a rebase; see the
 <a href="#setting-up-a-shared-repository" title="Setting up a shared repository">next section</a> and
-<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a>[git for CVS users] for more.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="setting-up-a-shared-repository"></a>Setting up a shared repository</h3></div></div></div><p>Another way to collaborate is by using a model similar to that
+<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a> for more.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="setting-up-a-shared-repository"></a>Setting up a shared repository</h3></div></div></div><p>Another way to collaborate is by using a model similar to that
 commonly used in CVS, where several developers with special rights
 all push to and pull from a single shared repository.  See
-<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a>[git for CVS users] for instructions on how to
+<a href="gitcvs-migration.html" target="_top">gitcvs-migration(7)</a> for instructions on how to
 set this up.</p><p>However, while there is nothing wrong with git's support for shared
 repositories, this mode of operation is not generally recommended,
 simply because the mode of collaboration that git supports—by
@@ -1093,7 +1092,7 @@ linear history:</p><pre class="literallayout">    ---Z---o---X--...---o---A---o-
 and understanding why Y* was broken would probably be easier.</p><p>Partly for this reason, many experienced git users, even when
 working on an otherwise merge-heavy project, keep the history
 linear by rebasing against the latest upstream version before
-publishing.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="advanced-branch-management"></a>Chapter 6. Advanced branch management</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="fetching-individual-branches"></a>Fetching individual branches</h2></div></div></div><p>Instead of using <a href="git-remote.html" target="_top">git-remote(1)</a>, you can also choose just
+publishing.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="advanced-branch-management"></a>Chapter 6. Advanced branch management</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git-fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="fetching-individual-branches"></a>Fetching individual branches</h2></div></div></div><p>Instead of using <a href="git-remote.html" target="_top">git-remote(1)</a>, you can also choose just
 to update one branch at a time, and to store it locally under an
 arbitrary name:</p><div class="literallayout"><p>$ git fetch origin todo:my-todo-work</p></div><p>The first argument, "origin", just tells git to fetch from the
 repository you originally cloned from.  The second argument tells git
@@ -1117,7 +1116,7 @@ resulting in a situation like:</p><pre class="literallayout"> o--o--o--o--a--b &
 described in the following section.  However, note that in the
 situation above this may mean losing the commits labeled "a" and "b",
 unless you've already created a reference of your own pointing to
-them.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="forcing-fetch"></a>Forcing git fetch to do non-fast-forward updates</h2></div></div></div><p>If git fetch fails because the new head of a branch is not a
+them.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="forcing-fetch"></a>Forcing git-fetch to do non-fast-forward updates</h2></div></div></div><p>If git fetch fails because the new head of a branch is not a
 descendant of the old head, you may force the update with:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git +master:refs/remotes/example/master</p></div><p>Note the addition of the "+" sign.  Alternatively, you can use the "-f"
 flag to force updates of all the fetched branches, as in:</p><div class="literallayout"><p>$ git fetch -f origin</p></div><p>Be aware that commits that the old version of example/master pointed at
 may be lost, as we saw in the previous section.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="remote-branch-configuration"></a>Configuring remote branches</h2></div></div></div><p>We saw above that "origin" is just a shortcut to refer to the
@@ -1135,7 +1134,7 @@ create similar configuration options to save typing; for example,
 after</p><div class="literallayout"><p>$ git config remote.example.url git://example.com/proj.git</p></div><p>then the following two commands will do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br>
 $ git fetch example master:refs/remotes/example/master</p></div><p>Even better, if you add one more option:</p><div class="literallayout"><p>$ git config remote.example.fetch master:refs/remotes/example/master</p></div><p>then the following commands will all do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br>
 $ git fetch example master:refs/remotes/example/master<br>
-$ git fetch example</p></div><p>You can also add a "+" to force the update each time:</p><div class="literallayout"><p>$ git config remote.example.fetch +master:ref/remotes/example/master</p></div><p>Don't do this unless you're sure you won't mind "git fetch" possibly
+$ git fetch example</p></div><p>You can also add a "+" to force the update each time:</p><div class="literallayout"><p>$ git config remote.example.fetch +master:ref/remotes/example/master</p></div><p>Don't do this unless you're sure you won't mind "git-fetch" possibly
 throwing away commits on mybranch.</p><p>Also note that all of the above configuration can be performed by
 directly editing the file .git/config instead of using
 <a href="git-config.html" target="_top">git-config(1)</a>.</p><p>See <a href="git-config.html" target="_top">git-config(1)</a> for more details on the configuration
@@ -1362,7 +1361,7 @@ to replace them by hand.  Back up your repository before attempting this
 in case you corrupt things even more in the process.</p><p>We'll assume that the problem is a single missing or corrupted blob,
 which is sometimes a solvable problem.  (Recovering missing trees and
 especially commits is <span class="strong"><strong>much</strong></span> harder).</p><p>Before starting, verify that there is corruption, and figure out where
-it is with <a href="git-fsck.html" target="_top">git-fsck(1)</a>; this may be time-consuming.</p><p>Assume the output looks like this:</p><div class="literallayout"><p>$ git-fsck --full<br>
+it is with <a href="git-fsck.html" target="_top">git-fsck(1)</a>; this may be time-consuming.</p><p>Assume the output looks like this:</p><div class="literallayout"><p>$ git fsck --full<br>
 broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8<br>
               to    blob 4b9458b3786228369c63936db65827de3cc06200<br>
 missing blob 4b9458b3786228369c63936db65827de3cc06200</p></div><p>(Typically there will be some "dangling object" messages too, but they
@@ -1441,7 +1440,7 @@ column in the <a href="git-ls-files.html" target="_top">git-ls-files(1)</a> outp
 number, and will take on values other than 0 for files with merge
 conflicts.</p></li></ol></div><p>The index is thus a sort of temporary staging area, which is filled with
 a tree which you are in the process of working on.</p><p>If you blow the index away entirely, you generally haven't lost any
-information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id280264">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules.  For
+information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id280263">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules.  For
 example, an embedded Linux distribution's source tree would include every
 piece of software in the distribution with some local modifications; a movie
 player might need to build against a specific, known-working version of a
@@ -1487,8 +1486,8 @@ $ git init<br>
 $ for i in a b c d<br>
 do<br>
         git submodule add ~/git/$i<br>
-done</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Do not use local URLs here if you plan to publish your superproject!</p></div><p>See what files <code class="literal">git submodule</code> created:</p><div class="literallayout"><p>$ ls -a<br>
-.  ..  .git  .gitmodules  a  b  c  d</p></div><p>The <code class="literal">git submodule add</code> command does a couple of things:</p><div class="itemizedlist"><ul type="disc"><li>
+done</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Do not use local URLs here if you plan to publish your superproject!</p></div><p>See what files <code class="literal">git-submodule</code> created:</p><div class="literallayout"><p>$ ls -a<br>
+.  ..  .git  .gitmodules  a  b  c  d</p></div><p>The <code class="literal">git-submodule add</code> command does a couple of things:</p><div class="itemizedlist"><ul type="disc"><li>
 It clones the submodule under the current directory and by default checks out
   the master branch.
 </li><li>
@@ -1508,12 +1507,12 @@ $ git submodule status<br>
 -d96249ff5d57de5de093e6baff9e0aafa5276a74 d</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The commit object names shown above would be different for you, but they
 should match the HEAD commit object names of your repositories.  You can check
 it by running <code class="literal">git ls-remote ../a</code>.</p></div><p>Pulling down the submodules is a two-step process. First run <code class="literal">git submodule
-init</code> to add the submodule repository URLs to <code class="literal">.git/config</code>:</p><div class="literallayout"><p>$ git submodule init</p></div><p>Now use <code class="literal">git submodule update</code> to clone the repositories and check out the
+init</code> to add the submodule repository URLs to <code class="literal">.git/config</code>:</p><div class="literallayout"><p>$ git submodule init</p></div><p>Now use <code class="literal">git-submodule update</code> to clone the repositories and check out the
 commits specified in the superproject:</p><div class="literallayout"><p>$ git submodule update<br>
 $ cd a<br>
 $ ls -a<br>
-.  ..  .git  a.txt</p></div><p>One major difference between <code class="literal">git submodule update</code> and <code class="literal">git submodule add</code> is
-that <code class="literal">git submodule update</code> checks out a specific commit, rather than the tip
+.  ..  .git  a.txt</p></div><p>One major difference between <code class="literal">git-submodule update</code> and <code class="literal">git-submodule add</code> is
+that <code class="literal">git-submodule update</code> checks out a specific commit, rather than the tip
 of a branch. It's like checking out a tag: the head is detached, so you're not
 working on a branch.</p><div class="literallayout"><p>$ git branch<br>
 * (no branch)<br>
@@ -1535,7 +1534,7 @@ index d266b98..261dfac 160000<br>
 $ git add a<br>
 $ git commit -m "Updated submodule a."<br>
 $ git push</p></div><p>You have to run <code class="literal">git submodule update</code> after <code class="literal">git pull</code> if you want to update
-submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id280264"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the
+submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id280263"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the
 superproject that references it. If you forget to publish the submodule change,
 others won't be able to clone the repository:</p><div class="literallayout"><p>$ cd ~/git/super/a<br>
 $ echo i added another line to this file &gt;&gt; a.txt<br>
@@ -1602,7 +1601,7 @@ use that tree to re-generate the index at any time by going in the
 other direction:</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-database-to-index"></a>object database -&gt; index</h3></div></div></div><p>You read a "tree" file from the object database, and use that to
 populate (and overwrite—don't do this if your index contains any
 unsaved state that you might want to restore later!) your current
-index.  Normal operation is just</p><div class="literallayout"><p>$ git-read-tree &lt;sha1 of tree&gt;</p></div><p>and your index file will now be equivalent to the tree that you saved
+index.  Normal operation is just</p><div class="literallayout"><p>$ git read-tree &lt;sha1 of tree&gt;</p></div><p>and your index file will now be equivalent to the tree that you saved
 earlier. However, that is only your <span class="emphasis"><em>index</em></span> file: your working
 directory contents have not been modified.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="index-to-working-directory"></a>index -&gt; working directory</h3></div></div></div><p>You update your working directory from the index by "checking out"
 files. This is not a very common operation, since normally you'd just
@@ -1611,7 +1610,7 @@ directory, you'd tell the index files about the changes in your
 working directory (i.e. <code class="literal">git-update-index</code>).</p><p>However, if you decide to jump to a new version, or check out somebody
 else's version, or just restore a previous tree, you'd populate your
 index file with read-tree, and then you need to check out the result
-with</p><div class="literallayout"><p>$ git-checkout-index filename</p></div><p>or, if you want to check out all of the index, use <code class="literal">-a</code>.</p><p>NOTE! git-checkout-index normally refuses to overwrite old files, so
+with</p><div class="literallayout"><p>$ git checkout-index filename</p></div><p>or, if you want to check out all of the index, use <code class="literal">-a</code>.</p><p>NOTE! git-checkout-index normally refuses to overwrite old files, so
 if you have an old version of the tree already checked out, you will
 need to use the "-f" flag (<span class="emphasis"><em>before</em></span> the "-a" flag or the filename) to
 <span class="emphasis"><em>force</em></span> the checkout.</p><p>Finally, there are a few odds and ends which are not purely moving
@@ -1625,7 +1624,7 @@ fact that such a commit brings together ("merges") two or more
 previous states represented by other commits.</p><p>In other words, while a "tree" represents a particular directory state
 of a working directory, a "commit" represents that state in "time",
 and explains how we got there.</p><p>You create a commit object by giving it the tree that describes the
-state at the time of the commit, and a list of parents:</p><div class="literallayout"><p>$ git-commit-tree &lt;tree&gt; -p &lt;parent&gt; [-p &lt;parent2&gt; ..]</p></div><p>and then giving the reason for the commit on stdin (either through
+state at the time of the commit, and a list of parents:</p><div class="literallayout"><p>$ git commit-tree &lt;tree&gt; -p &lt;parent&gt; [-p &lt;parent2&gt; ..]</p></div><p>and then giving the reason for the commit on stdin (either through
 redirection from a pipe or file, or by just typing it at the tty).</p><p>git-commit-tree will return the name of the object that represents
 that commit, and you should save it away for later use. Normally,
 you'd commit a new <code class="literal">HEAD</code> state, and while git doesn't care where you
@@ -1667,14 +1666,14 @@ various pieces fit together.</p><div class="literallayout"><p><br>
 </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="examining-the-data"></a>Examining the data</h2></div></div></div><p>You can examine the data represented in the object database and the
 index with various helper tools. For every object, you can use
 <a href="git-cat-file.html" target="_top">git-cat-file(1)</a> to examine details about the
-object:</p><div class="literallayout"><p>$ git-cat-file -t &lt;objectname&gt;</p></div><p>shows the type of the object, and once you have the type (which is
-usually implicit in where you find the object), you can use</p><div class="literallayout"><p>$ git-cat-file blob|tree|commit|tag &lt;objectname&gt;</p></div><p>to show its contents. NOTE! Trees have binary content, and as a result
+object:</p><div class="literallayout"><p>$ git cat-file -t &lt;objectname&gt;</p></div><p>shows the type of the object, and once you have the type (which is
+usually implicit in where you find the object), you can use</p><div class="literallayout"><p>$ git cat-file blob|tree|commit|tag &lt;objectname&gt;</p></div><p>to show its contents. NOTE! Trees have binary content, and as a result
 there is a special helper for showing that content, called
 <code class="literal">git-ls-tree</code>, which turns the binary content into a more easily
 readable form.</p><p>It's especially instructive to look at "commit" objects, since those
 tend to be small and fairly self-explanatory. In particular, if you
 follow the convention of having the top commit name in <code class="literal">.git/HEAD</code>,
-you can do</p><div class="literallayout"><p>$ git-cat-file commit HEAD</p></div><p>to see what the top commit was.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git helps you do a three-way merge, which you can expand to n-way by
+you can do</p><div class="literallayout"><p>$ git cat-file commit HEAD</p></div><p>to see what the top commit was.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git helps you do a three-way merge, which you can expand to n-way by
 repeating the merge procedure arbitrary times until you finally
 "commit" the state.  The normal situation is that you'd only do one
 three-way merge (two parents), and commit it, but if you like to, you
@@ -1682,28 +1681,28 @@ can do multiple parents in one go.</p><p>To do a three-way merge, you need the t
 that you want to merge, use those to find the closest common parent (a
 third "commit" object), and then use those commit objects to find the
 state of the directory ("tree" object) at these points.</p><p>To get the "base" for the merge, you first look up the common parent
-of two commits with</p><div class="literallayout"><p>$ git-merge-base &lt;commit1&gt; &lt;commit2&gt;</p></div><p>which will return you the commit they are both based on.  You should
+of two commits with</p><div class="literallayout"><p>$ git merge-base &lt;commit1&gt; &lt;commit2&gt;</p></div><p>which will return you the commit they are both based on.  You should
 now look up the "tree" objects of those commits, which you can easily
-do with (for example)</p><div class="literallayout"><p>$ git-cat-file commit &lt;commitname&gt; | head -1</p></div><p>since the tree object information is always the first line in a commit
+do with (for example)</p><div class="literallayout"><p>$ git cat-file commit &lt;commitname&gt; | head -1</p></div><p>since the tree object information is always the first line in a commit
 object.</p><p>Once you know the three trees you are going to merge (the one "original"
 tree, aka the common tree, and the two "result" trees, aka the branches
 you want to merge), you do a "merge" read into the index. This will
 complain if it has to throw away your old index contents, so you should
 make sure that you've committed those—in fact you would normally
 always do a merge against your last commit (which should thus match what
-you have in your current index anyway).</p><p>To do the merge, do</p><div class="literallayout"><p>$ git-read-tree -m -u &lt;origtree&gt; &lt;yourtree&gt; &lt;targettree&gt;</p></div><p>which will do all trivial merge operations for you directly in the
+you have in your current index anyway).</p><p>To do the merge, do</p><div class="literallayout"><p>$ git read-tree -m -u &lt;origtree&gt; &lt;yourtree&gt; &lt;targettree&gt;</p></div><p>which will do all trivial merge operations for you directly in the
 index file, and you can just write the result out with
 <code class="literal">git-write-tree</code>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees-2"></a>Merging multiple trees, continued</h2></div></div></div><p>Sadly, many merges aren't trivial. If there are files that have
 been added, moved or removed, or if both branches have modified the
 same file, you will be left with an index tree that contains "merge
 entries" in it. Such an index tree can <span class="emphasis"><em>NOT</em></span> be written out to a tree
 object, and you will have to resolve any such merge clashes using
-other tools before you can write out the result.</p><p>You can examine such index state with <code class="literal">git-ls-files —unmerged</code>
-command.  An example:</p><div class="literallayout"><p>$ git-read-tree -m $orig HEAD $target<br>
-$ git-ls-files --unmerged<br>
+other tools before you can write out the result.</p><p>You can examine such index state with <code class="literal">git ls-files —unmerged</code>
+command.  An example:</p><div class="literallayout"><p>$ git read-tree -m $orig HEAD $target<br>
+$ git ls-files --unmerged<br>
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1       hello.c<br>
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2       hello.c<br>
-100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello.c</p></div><p>Each line of the <code class="literal">git-ls-files —unmerged</code> output begins with
+100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello.c</p></div><p>Each line of the <code class="literal">git ls-files —unmerged</code> output begins with
 the blob mode bits, blob SHA1, <span class="emphasis"><em>stage number</em></span>, and the
 filename.  The <span class="emphasis"><em>stage number</em></span> is git's way to say which tree it
 came from: stage 1 corresponds to <code class="literal">$orig</code> tree, stage 2 <code class="literal">HEAD</code>
@@ -1716,19 +1715,19 @@ above example shows is that file <code class="literal">hello.c</code> was change
 <code class="literal">$orig</code> to <code class="literal">HEAD</code> and <code class="literal">$orig</code> to <code class="literal">$target</code> in a different way.
 You could resolve this by running your favorite 3-way merge
 program, e.g.  <code class="literal">diff3</code>, <code class="literal">merge</code>, or git's own merge-file, on
-the blob objects from these three stages yourself, like this:</p><div class="literallayout"><p>$ git-cat-file blob 263414f... &gt;hello.c~1<br>
-$ git-cat-file blob 06fa6a2... &gt;hello.c~2<br>
-$ git-cat-file blob cc44c73... &gt;hello.c~3<br>
+the blob objects from these three stages yourself, like this:</p><div class="literallayout"><p>$ git cat-file blob 263414f... &gt;hello.c~1<br>
+$ git cat-file blob 06fa6a2... &gt;hello.c~2<br>
+$ git cat-file blob cc44c73... &gt;hello.c~3<br>
 $ git merge-file hello.c~2 hello.c~1 hello.c~3</p></div><p>This would leave the merge result in <code class="literal">hello.c~2</code> file, along
 with conflict markers if there are conflicts.  After verifying
 the merge result makes sense, you can tell git what the final
 merge result for this file is by:</p><div class="literallayout"><p>$ mv -f hello.c~2 hello.c<br>
-$ git-update-index hello.c</p></div><p>When a path is in unmerged state, running <code class="literal">git-update-index</code> for
+$ git update-index hello.c</p></div><p>When a path is in unmerged state, running <code class="literal">git-update-index</code> for
 that path tells git to mark the path resolved.</p><p>The above is the description of a git merge at the lowest level,
 to help you understand what conceptually happens under the hood.
 In practice, nobody, not even git itself, uses three <code class="literal">git-cat-file</code>
 for this.  There is <code class="literal">git-merge-index</code> program that extracts the
-stages to temporary files and calls a "merge" script on it:</p><div class="literallayout"><p>$ git-merge-index git-merge-one-file hello.c</p></div><p>and that is what higher level <code class="literal">git merge -s resolve</code> is implemented with.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="hacking-git"></a>Chapter 10. Hacking git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></div><p>This chapter covers internal details of the git implementation which
+stages to temporary files and calls a "merge" script on it:</p><div class="literallayout"><p>$ git merge-index git-merge-one-file hello.c</p></div><p>and that is what higher level <code class="literal">git-merge -s resolve</code> is implemented with.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="hacking-git"></a>Chapter 10. Hacking git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></div><p>This chapter covers internal details of the git implementation which
 probably only git developers need to understand.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="object-details"></a>Object storage format</h2></div></div></div><p>All objects have a statically determined "type" which identifies the
 format of the object (i.e. how it is used, and how it can refer to other
 objects).  There are currently four different object types: "blob",
@@ -1790,7 +1789,7 @@ parsing after calling <code class="literal">setup_revisions()</code>. After that
 <code class="literal">prepare_revision_walk()</code> for initialization, and then you can get the
 commits one by one with the function <code class="literal">get_revision()</code>.</p><p>If you are interested in more details of the revision walking process,
 just have a look at the first implementation of <code class="literal">cmd_log()</code>; call
-<code class="literal">git-show v1.3.0~155^2~4</code> and scroll down to that function (note that you
+<code class="literal">git show v1.3.0~155^2~4</code> and scroll down to that function (note that you
 no longer need to call <code class="literal">setup_pager()</code> directly).</p><p>Nowadays, <code class="literal">git log</code> is a builtin, which means that it is _contained_ in the
 command <code class="literal">git</code>.  The source side of a builtin is</p><div class="itemizedlist"><ul type="disc"><li>
 a function called <code class="literal">cmd_&lt;bla&gt;</code>, typically defined in <code class="literal">builtin-&lt;bla&gt;.c</code>,
@@ -1839,8 +1838,8 @@ object).  To know how the function <code class="literal">read_object_with_refere
 works, find the source code for it (something like <code class="literal">git grep
 read_object_with | grep ":[a-z]"</code> in the git repository), and read
 the source.</p><p>To find out how the result can be used, just read on in <code class="literal">cmd_cat_file()</code>:</p><div class="literallayout"><p>        write_or_die(1, buf, size);</p></div><p>Sometimes, you do not know where to look for a feature.  In many such cases,
-it helps to search through the output of <code class="literal">git log</code>, and then <code class="literal">git show</code> the
-corresponding commit.</p><p>Example: If you know that there was some test case for <code class="literal">git bundle</code>, but
+it helps to search through the output of <code class="literal">git log</code>, and then <code class="literal">git-show</code> the
+corresponding commit.</p><p>Example: If you know that there was some test case for <code class="literal">git-bundle</code>, but
 do not remember where it was (yes, you _could_ <code class="literal">git grep bundle t/</code>, but that
 does not illustrate the point!):</p><div class="literallayout"><p>$ git log --no-merges t/</p></div><p>In the pager (<code class="literal">less</code>), just search for "bundle", go a few lines back,
 and see that it is in commit 18449ab0…  Now just copy this object name,
diff --git a/user-manual.txt b/user-manual.txt
index 64a820bf6..ca13266b1 100644
--- a/user-manual.txt
+++ b/user-manual.txt
@@ -18,7 +18,7 @@ People needing to do actual development will also want to read
 Further chapters cover more specialized topics.
 
 Comprehensive reference documentation is available through the man
-pages.  For a command such as "git clone", just use
+pages.  For a command such as "git clone <repo>", just use
 
 ------------------------------------------------
 $ man git-clone
@@ -178,7 +178,7 @@ As you can see, a commit shows who made the latest change, what they
 did, and why.
 
 Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA1 id", shown on the first line of the "git show" output.  You can usually
+"SHA1 id", shown on the first line of the "git-show" output.  You can usually
 refer to a commit by a shorter name, such as a tag or a branch name, but this
 longer name can also be useful.  Most importantly, it is a globally unique
 name for this commit: so if you tell somebody else the object name (for
@@ -390,7 +390,7 @@ references with the same shorthand name, see the "SPECIFYING
 REVISIONS" section of linkgit:git-rev-parse[1].
 
 [[Updating-a-repository-with-git-fetch]]
-Updating a repository with git fetch
+Updating a repository with git-fetch
 ------------------------------------
 
 Eventually the developer cloned from will do additional work in her
@@ -417,7 +417,7 @@ $ git fetch linux-nfs
 -------------------------------------------------
 
 New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave "git-remote add", in this case linux-nfs:
 
 -------------------------------------------------
 $ git branch -r
@@ -1048,7 +1048,7 @@ $ git diff
 
 shows the difference between the working tree and the index file.
 
-Note that "git add" always adds just the current contents of a file
+Note that "git-add" always adds just the current contents of a file
 to the index; further changes to the same file will be ignored unless
 you run git-add on the file again.
 
@@ -1111,7 +1111,7 @@ Ignoring files
 A project will often generate files that you do 'not' want to track with git.
 This typically includes files generated by a build process or temporary
 backup files made by your editor. Of course, 'not' tracking files with git
-is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
+is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes
 annoying to have these untracked files lying around; e.g. they make
 "`git add .`" and "`git commit -a`" practically useless, and they keep
 showing up in the output of "`git status`".
@@ -1449,7 +1449,7 @@ Checking out an old version of a file
 
 In the process of undoing a previous bad change, you may find it
 useful to check out an older version of a particular file using
-linkgit:git-checkout[1].  We've used git checkout before to switch
+linkgit:git-checkout[1].  We've used git-checkout before to switch
 branches, but it has quite different behavior if it is given a path
 name: the command
 
@@ -1651,7 +1651,7 @@ Sharing development with others
 ===============================
 
 [[getting-updates-with-git-pull]]
-Getting updates with git pull
+Getting updates with git-pull
 -----------------------------
 
 After you clone a repository and make a few changes of your own, you
@@ -1770,7 +1770,7 @@ Public git repositories
 Another way to submit changes to a project is to tell the maintainer
 of that project to pull the changes from your repository using
 linkgit:git-pull[1].  In the section "<<getting-updates-with-git-pull,
-Getting updates with git pull>>" we described this as a way to get
+Getting updates with git-pull>>" we described this as a way to get
 updates from the "main" repository, but it works just as well in the
 other direction.
 
@@ -1879,8 +1879,7 @@ $ chmod a+x hooks/post-update
 -------------------------------------------------
 
 (For an explanation of the last two lines, see
-linkgit:git-update-server-info[1], and the documentation
-linkgit:githooks[5][Hooks used by git].)
+linkgit:git-update-server-info[1] and linkgit:githooks[5].)
 
 Advertise the URL of proj.git.  Anybody else should then be able to
 clone or pull from that URL, for example with a command line like:
@@ -1992,7 +1991,7 @@ the right to push to the same repository.  In that case, the correct
 solution is to retry the push after first updating your work by either a
 pull or a fetch followed by a rebase; see the
 <<setting-up-a-shared-repository,next section>> and
-linkgit:gitcvs-migration[7][git for CVS users] for more.
+linkgit:gitcvs-migration[7] for more.
 
 [[setting-up-a-shared-repository]]
 Setting up a shared repository
@@ -2001,7 +2000,7 @@ Setting up a shared repository
 Another way to collaborate is by using a model similar to that
 commonly used in CVS, where several developers with special rights
 all push to and pull from a single shared repository.  See
-linkgit:gitcvs-migration[7][git for CVS users] for instructions on how to
+linkgit:gitcvs-migration[7] for instructions on how to
 set this up.
 
 However, while there is nothing wrong with git's support for shared
@@ -2736,7 +2735,7 @@ unless you've already created a reference of your own pointing to
 them.
 
 [[forcing-fetch]]
-Forcing git fetch to do non-fast-forward updates
+Forcing git-fetch to do non-fast-forward updates
 ------------------------------------------------
 
 If git fetch fails because the new head of a branch is not a
@@ -2811,7 +2810,7 @@ You can also add a "+" to force the update each time:
 $ git config remote.example.fetch +master:ref/remotes/example/master
 -------------------------------------------------
 
-Don't do this unless you're sure you won't mind "git fetch" possibly
+Don't do this unless you're sure you won't mind "git-fetch" possibly
 throwing away commits on mybranch.
 
 Also note that all of the above configuration can be performed by
@@ -3235,7 +3234,7 @@ it is with linkgit:git-fsck[1]; this may be time-consuming.
 Assume the output looks like this:
 
 ------------------------------------------------
-$ git-fsck --full
+$ git fsck --full
 broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
               to    blob 4b9458b3786228369c63936db65827de3cc06200
 missing blob 4b9458b3786228369c63936db65827de3cc06200
@@ -3465,14 +3464,14 @@ done
 
 NOTE: Do not use local URLs here if you plan to publish your superproject!
 
-See what files `git submodule` created:
+See what files `git-submodule` created:
 
 -------------------------------------------------
 $ ls -a
 .  ..  .git  .gitmodules  a  b  c  d
 -------------------------------------------------
 
-The `git submodule add` command does a couple of things:
+The `git-submodule add` command does a couple of things:
 
 - It clones the submodule under the current directory and by default checks out
   the master branch.
@@ -3518,7 +3517,7 @@ init` to add the submodule repository URLs to `.git/config`:
 $ git submodule init
 -------------------------------------------------
 
-Now use `git submodule update` to clone the repositories and check out the
+Now use `git-submodule update` to clone the repositories and check out the
 commits specified in the superproject:
 
 -------------------------------------------------
@@ -3528,8 +3527,8 @@ $ ls -a
 .  ..  .git  a.txt
 -------------------------------------------------
 
-One major difference between `git submodule update` and `git submodule add` is
-that `git submodule update` checks out a specific commit, rather than the tip
+One major difference between `git-submodule update` and `git-submodule add` is
+that `git-submodule update` checks out a specific commit, rather than the tip
 of a branch. It's like checking out a tag: the head is detached, so you're not
 working on a branch.
 
@@ -3730,7 +3729,7 @@ unsaved state that you might want to restore later!) your current
 index.  Normal operation is just
 
 -------------------------------------------------
-$ git-read-tree <sha1 of tree>
+$ git read-tree <sha1 of tree>
 -------------------------------------------------
 
 and your index file will now be equivalent to the tree that you saved
@@ -3753,7 +3752,7 @@ index file with read-tree, and then you need to check out the result
 with
 
 -------------------------------------------------
-$ git-checkout-index filename
+$ git checkout-index filename
 -------------------------------------------------
 
 or, if you want to check out all of the index, use `-a`.
@@ -3790,7 +3789,7 @@ You create a commit object by giving it the tree that describes the
 state at the time of the commit, and a list of parents:
 
 -------------------------------------------------
-$ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
+$ git commit-tree <tree> -p <parent> [-p <parent2> ..]
 -------------------------------------------------
 
 and then giving the reason for the commit on stdin (either through
@@ -3853,14 +3852,14 @@ linkgit:git-cat-file[1] to examine details about the
 object:
 
 -------------------------------------------------
-$ git-cat-file -t <objectname>
+$ git cat-file -t <objectname>
 -------------------------------------------------
 
 shows the type of the object, and once you have the type (which is
 usually implicit in where you find the object), you can use
 
 -------------------------------------------------
-$ git-cat-file blob|tree|commit|tag <objectname>
+$ git cat-file blob|tree|commit|tag <objectname>
 -------------------------------------------------
 
 to show its contents. NOTE! Trees have binary content, and as a result
@@ -3874,7 +3873,7 @@ follow the convention of having the top commit name in `.git/HEAD`,
 you can do
 
 -------------------------------------------------
-$ git-cat-file commit HEAD
+$ git cat-file commit HEAD
 -------------------------------------------------
 
 to see what the top commit was.
@@ -3898,7 +3897,7 @@ To get the "base" for the merge, you first look up the common parent
 of two commits with
 
 -------------------------------------------------
-$ git-merge-base <commit1> <commit2>
+$ git merge-base <commit1> <commit2>
 -------------------------------------------------
 
 which will return you the commit they are both based on.  You should
@@ -3906,7 +3905,7 @@ now look up the "tree" objects of those commits, which you can easily
 do with (for example)
 
 -------------------------------------------------
-$ git-cat-file commit <commitname> | head -1
+$ git cat-file commit <commitname> | head -1
 -------------------------------------------------
 
 since the tree object information is always the first line in a commit
@@ -3923,7 +3922,7 @@ you have in your current index anyway).
 To do the merge, do
 
 -------------------------------------------------
-$ git-read-tree -m -u <origtree> <yourtree> <targettree>
+$ git read-tree -m -u <origtree> <yourtree> <targettree>
 -------------------------------------------------
 
 which will do all trivial merge operations for you directly in the
@@ -3942,18 +3941,18 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
 object, and you will have to resolve any such merge clashes using
 other tools before you can write out the result.
 
-You can examine such index state with `git-ls-files --unmerged`
+You can examine such index state with `git ls-files --unmerged`
 command.  An example:
 
 ------------------------------------------------
-$ git-read-tree -m $orig HEAD $target
-$ git-ls-files --unmerged
+$ git read-tree -m $orig HEAD $target
+$ git ls-files --unmerged
 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1	hello.c
 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2	hello.c
 100644 cc44c73eb783565da5831b4d820c962954019b69 3	hello.c
 ------------------------------------------------
 
-Each line of the `git-ls-files --unmerged` output begins with
+Each line of the `git ls-files --unmerged` output begins with
 the blob mode bits, blob SHA1, 'stage number', and the
 filename.  The 'stage number' is git's way to say which tree it
 came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
@@ -3971,9 +3970,9 @@ program, e.g.  `diff3`, `merge`, or git's own merge-file, on
 the blob objects from these three stages yourself, like this:
 
 ------------------------------------------------
-$ git-cat-file blob 263414f... >hello.c~1
-$ git-cat-file blob 06fa6a2... >hello.c~2
-$ git-cat-file blob cc44c73... >hello.c~3
+$ git cat-file blob 263414f... >hello.c~1
+$ git cat-file blob 06fa6a2... >hello.c~2
+$ git cat-file blob cc44c73... >hello.c~3
 $ git merge-file hello.c~2 hello.c~1 hello.c~3
 ------------------------------------------------
 
@@ -3984,7 +3983,7 @@ merge result for this file is by:
 
 -------------------------------------------------
 $ mv -f hello.c~2 hello.c
-$ git-update-index hello.c
+$ git update-index hello.c
 -------------------------------------------------
 
 When a path is in unmerged state, running `git-update-index` for
@@ -3997,10 +3996,10 @@ for this.  There is `git-merge-index` program that extracts the
 stages to temporary files and calls a "merge" script on it:
 
 -------------------------------------------------
-$ git-merge-index git-merge-one-file hello.c
+$ git merge-index git-merge-one-file hello.c
 -------------------------------------------------
 
-and that is what higher level `git merge -s resolve` is implemented with.
+and that is what higher level `git-merge -s resolve` is implemented with.
 
 [[hacking-git]]
 Hacking git
@@ -4128,7 +4127,7 @@ commits one by one with the function `get_revision()`.
 
 If you are interested in more details of the revision walking process,
 just have a look at the first implementation of `cmd_log()`; call
-`git-show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
+`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
 no longer need to call `setup_pager()` directly).
 
 Nowadays, `git log` is a builtin, which means that it is _contained_ in the
@@ -4219,10 +4218,10 @@ To find out how the result can be used, just read on in `cmd_cat_file()`:
 -----------------------------------
 
 Sometimes, you do not know where to look for a feature.  In many such cases,
-it helps to search through the output of `git log`, and then `git show` the
+it helps to search through the output of `git log`, and then `git-show` the
 corresponding commit.
 
-Example: If you know that there was some test case for `git bundle`, but
+Example: If you know that there was some test case for `git-bundle`, but
 do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
 does not illustrate the point!):
 
-- 
2.26.2