Protect characters being misinterpreted as markup (_, <, and >).

diff --git a/tour.mdwn b/tour.mdwn
index 2b10eb83de8ff4ec901b9044c2ad09f9cef13129..2d209d76c130042d61ac181bcc65f4f34e725e25 100644 (file)
--- a/tour.mdwn
+++ b/tour.mdwn
@@ -121,8 +121,8 @@ command. If you are completely stuck, simply run “git help”; it will
 print a brief list of commonly-used commands, along with a description
 of what each does. If you ask for help on a specific command (such as
 "git help init"), it prints more detailed information. [XXX: Does "git
-help <foo>" work universally as a built-in or does it expect man to be
-present and just call out to "man git-<foo>"?]
+help \<foo\>" work universally as a built-in or does it expect man to be
+present and just call out to "man git-\<foo\>"?]
 
        [XXX: The original hgbook includes the complete output of "hg
        help init" at this point. I'm not including the corresponding
@@ -525,10 +525,10 @@ conventions for options that are common to modern Linux and Unix
 systems.
 
   * Most options have long names. For example, as we’ve already seen,
-    the “git log" command accepts a --max-count=<number> option.
+    the “git log" command accepts a --max-count=\<number\> option.
   * Some options have short, single-character names. Often these are
-    aliases for long commands, (such as "-n <number>" instead of
-    --max-count=<number>), but sometimes the option exists in
+    aliases for long commands, (such as "-n \<number\>" instead of
+    --max-count=\<number\>), but sometimes the option exists in
     short-form with no long-form equivalent, (such as -p). [XXX: It
     wouldn't hurt to fix this by adding --patch, etc. right?]
   * Long options start with two dashes (e.g. --max-count), while short
@@ -643,13 +643,13 @@ attempt each of the following methods, in order, (stopping for each of
 the author and committer name and email as soon as a value is found):
 
   1. If you specify a --author option to the “git commit” command on
-     the command line, followed by a "Real Name <email@example.com>"
+     the command line, followed by a "Real Name \<email@example.com\>"
      string, then this name and addresss will be used for the author
      fields. The committer fields will still be determined as
      below. This option is very helpful for when applying a commit
      originally authored by someone other than yourself.
-  2. If any of the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
-     GIT_COMMITTER_NAME, or GIT_COMMITER_EMAIL environment variables
+  2. If any of the `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`,
+     `GIT_COMMITTER`_NAME, or `GIT_COMMITER_EMAIL` environment variables
      are set, then those values will be used for the corresponding
      fields.
   3. If you have a file in your home directory called .gitconfig, with
@@ -661,7 +661,7 @@ the author and committer name and email as soon as a value is found):
      again with name or email settings in the [user] section, then
      these values will be used to set any remaining author and
      committer fields.
-  5. If you have set the EMAIL environment variable, this will be used
+  5. If you have set the `EMAIL` environment variable, this will be used
      to set author and committer email addresses if still unset.
   6. git will query your system to find out your real name from
      available GECOS field and your username, hostname, and domain to
@@ -672,7 +672,7 @@ If all of these mechanisms fail, "git commit" will fail, printing an
 error message instructing you how to use "git config" to tell git your
 name and email address.
 
-You should think of the GIT_AUTHOR/COMMITER_NAME/EMAIL environment
+You should think of the `GIT_AUTHOR`/`COMMITER_NAME`/`EMAIL` environment
 variables and the --author option to the “git commit” command as ways
 to override git’s default selection. For normal use, the simplest and
 most robust way to set your information is by creating a .gitconfig
@@ -745,12 +745,12 @@ after we’ve finished committing.
 Note: The -a on the command-line instructs git to commit the new
 content of *all* tracked files that have been modified. This is a
 convenience over explicitly listing filenames to be committed on the
-"git commit" command line. It is useful to use "git commit <files>"
+"git commit" command line. It is useful to use "git commit \<files\>"
 when there is a need to commit only some subset of the files that have
 been modified.
 
 If new files need to be committed for the first time, just use "git
-add <file>" before "git commit -a". If a file needs to be removed,
+add \<file\>" before "git commit -a". If a file needs to be removed,
 just remove it as normal before committing and "git commit -a" will
 notice that---it does not need to be explicitly told about the
 removal.