Documentation: AsciiDoc spells em-dash as double-dashes, not triple
authorJunio C Hamano <gitster@pobox.com>
Thu, 22 Oct 2015 20:02:33 +0000 (13:02 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 22 Oct 2015 20:02:33 +0000 (13:02 -0700)
Again, we do not usually process release notes with AsciiDoc, but it
is better to be consistent.

This incidentally reveals breakages left by an ancient 5e00439f
(Documentation: build html for all files in technical and howto,
2012-10-23). The index-format documentation was originally written
to be read as straight text without formatting and when the commit
forced everything in Documentation/ to go through AsciiDoc, it did
not do any adjustment--hence the double-dashes will be seen in the
resulting text that is rendered as preformatted fixed-width without
converted into em-dashes.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/RelNotes/1.7.7.txt
Documentation/RelNotes/1.9.0.txt
Documentation/git-bisect.txt
Documentation/git-fetch.txt
Documentation/git-push.txt
Documentation/technical/index-format.txt
index 7655cccfaa1585a14257b5a86d663f501c06bf1d..6eff128c80b706822f62bfdd19f7b127df47d286 100644 (file)
@@ -84,7 +84,7 @@ Updates since v1.7.6
    logic used by "git diff" to determine the hunk header.
 
  * Invoking the low-level "git http-fetch" without "-a" option (which
    logic used by "git diff" to determine the hunk header.
 
  * Invoking the low-level "git http-fetch" without "-a" option (which
-   git itself never did---normal users should not have to worry about
+   git itself never did--normal users should not have to worry about
    this) is now deprecated.
 
  * The "--decorate" option to "git log" and its family learned to
    this) is now deprecated.
 
  * The "--decorate" option to "git log" and its family learned to
index 752d79127a3d7a4aa25df28f1c659b46ee527f35..4e4b88aa5c89440c94df7322398a4b83b9961b01 100644 (file)
@@ -177,7 +177,7 @@ Performance, Internal Implementation, etc.
  * The naming convention of the packfiles has been updated; it used to
    be based on the enumeration of names of the objects that are
    contained in the pack, but now it also depends on how the packed
  * The naming convention of the packfiles has been updated; it used to
    be based on the enumeration of names of the objects that are
    contained in the pack, but now it also depends on how the packed
-   result is represented---packing the same set of objects using
+   result is represented--packing the same set of objects using
    different settings (or delta order) would produce a pack with
    different name.
 
    different settings (or delta order) would produce a pack with
    different name.
 
index 4cb52a7302077e17d5a05983a5e6c924b4694194..617efa0559eb6b64af0b4776b3fa5dcd55da8af5 100644 (file)
@@ -245,7 +245,7 @@ cannot be tested. If the script exits with this code, the current
 revision will be skipped (see `git bisect skip` above). 125 was chosen
 as the highest sensible value to use for this purpose, because 126 and 127
 are used by POSIX shells to signal specific error status (127 is for
 revision will be skipped (see `git bisect skip` above). 125 was chosen
 as the highest sensible value to use for this purpose, because 126 and 127
 are used by POSIX shells to signal specific error status (127 is for
-command not found, 126 is for command found but not executable---these
+command not found, 126 is for command found but not executable--these
 details do not matter, as they are normal errors in the script, as far as
 "bisect run" is concerned).
 
 details do not matter, as they are normal errors in the script, as far as
 "bisect run" is concerned).
 
index 8deb61469d9cbd8786c27567851158c90c31aa8a..ee51c1adea51eadc29a68f0f395fabc3a79cd008 100644 (file)
@@ -71,7 +71,7 @@ This configuration is used in two ways:
 * When `git fetch` is run without specifying what branches
   and/or tags to fetch on the command line, e.g. `git fetch origin`
   or `git fetch`, `remote.<repository>.fetch` values are used as
 * When `git fetch` is run without specifying what branches
   and/or tags to fetch on the command line, e.g. `git fetch origin`
   or `git fetch`, `remote.<repository>.fetch` values are used as
-  the refspecs---they specify which refs to fetch and which local refs
+  the refspecs--they specify which refs to fetch and which local refs
   to update.  The example above will fetch
   all branches that exist in the `origin` (i.e. any ref that matches
   the left-hand side of the value, `refs/heads/*`) and update the
   to update.  The example above will fetch
   all branches that exist in the `origin` (i.e. any ref that matches
   the left-hand side of the value, `refs/heads/*`) and update the
index b17283ab7a1cc73c5ec741e0da1128bea2a57a65..3267e2111e83c24bb57dd037a7932c208bd27805 100644 (file)
@@ -61,7 +61,7 @@ be named.
 If `git push [<repository>]` without any `<refspec>` argument is set to
 update some ref at the destination with `<src>` with
 `remote.<repository>.push` configuration variable, `:<dst>` part can
 If `git push [<repository>]` without any `<refspec>` argument is set to
 update some ref at the destination with `<src>` with
 `remote.<repository>.push` configuration variable, `:<dst>` part can
-be omitted---such a push will update a ref that `<src>` normally updates
+be omitted--such a push will update a ref that `<src>` normally updates
 without any `<refspec>` on the command line.  Otherwise, missing
 `:<dst>` means to update the same ref as the `<src>`.
 +
 without any `<refspec>` on the command line.  Otherwise, missing
 `:<dst>` means to update the same ref as the `<src>`.
 +
index 1250b5ca8b8abc0d1da0bb94d8391fb14f155693..61cb55d02ad93459f2b428b1e7a62165d2e5439d 100644 (file)
@@ -170,7 +170,7 @@ Git index format
 
   The entries are written out in the top-down, depth-first order.  The
   first entry represents the root level of the repository, followed by the
 
   The entries are written out in the top-down, depth-first order.  The
   first entry represents the root level of the repository, followed by the
-  first subtree---let's call this A---of the root level (with its name
+  first subtree--let's call this A--of the root level (with its name
   relative to the root level), followed by the first subtree of A (with
   its name relative to A), ...
 
   relative to the root level), followed by the first subtree of A (with
   its name relative to A), ...