manual: Fix or remove em dashes.

em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c7fdf25e27c94e9b152592a28bf7acc64dfa0e07..975dc96f9dd8c78b40c9e9d4eea925d06b566c12 100644 (file)
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2756,7 +2756,7 @@ There are four different types of objects: "blob", "tree", "commit", and
   "blob" objects into a directory structure. In addition, a tree object
   can refer to other tree objects, thus creating a directory hierarchy.
 - A <<def_commit_object,"commit" object>> ties such directory hierarchies
   "blob" objects into a directory structure. In addition, a tree object
   can refer to other tree objects, thus creating a directory hierarchy.
 - A <<def_commit_object,"commit" object>> ties such directory hierarchies

-  together into a <<def_DAG,directed acyclic graph>> of revisions - each
+  together into a <<def_DAG,directed acyclic graph>> of revisions--each

   commit contains the object name of exactly one tree designating the
   directory hierarchy at the time of the commit. In addition, a commit
   refers to "parent" commit objects that describe the history of how we
   commit contains the object name of exactly one tree designating the
   directory hierarchy at the time of the commit. In addition, a commit
   refers to "parent" commit objects that describe the history of how we


@@ -3029,7 +3029,7 @@ There are also other situations that cause dangling objects. For
 example, a "dangling blob" may arise because you did a "git add" of a
 file, but then, before you actually committed it and made it part of the
 bigger picture, you changed something else in that file and committed
 example, a "dangling blob" may arise because you did a "git add" of a
 file, but then, before you actually committed it and made it part of the
 bigger picture, you changed something else in that file and committed

-that *updated* thing - the old state that you added originally ends up
+that *updated* thing--the old state that you added originally ends up

 not being pointed to by any commit or tree, so it's now a dangling blob
 object.
 
 not being pointed to by any commit or tree, so it's now a dangling blob
 object.
 


@@ -3044,7 +3044,7 @@ up pointing to them, so they end up "dangling" in your repository.
 Generally, dangling objects aren't anything to worry about. They can
 even be very useful: if you screw something up, the dangling objects can
 be how you recover your old tree (say, you did a rebase, and realized
 Generally, dangling objects aren't anything to worry about. They can
 even be very useful: if you screw something up, the dangling objects can
 be how you recover your old tree (say, you did a rebase, and realized

-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to--you can look at what dangling objects

 you have, and decide to reset your head to some old dangling state).
 
 For commits, you can just use:
 you have, and decide to reset your head to some old dangling state).
 
 For commits, you can just use:


@@ -3088,10 +3088,10 @@ $ git prune
 ------------------------------------------------
 
 and they'll be gone. But you should only run "git prune" on a quiescent
 ------------------------------------------------
 
 and they'll be gone. But you should only run "git prune" on a quiescent

-repository - it's kind of like doing a filesystem fsck recovery: you
+repository--it's kind of like doing a filesystem fsck recovery: you

 don't want to do that while the filesystem is mounted.
 
 don't want to do that while the filesystem is mounted.
 

-(The same is true of "git-fsck" itself, btw - but since
+(The same is true of "git-fsck" itself, btw, but since

 git-fsck never actually *changes* the repository, it just reports
 on what it found, git-fsck itself is never "dangerous" to run.
 Running it while somebody is actually changing the repository can cause
 git-fsck never actually *changes* the repository, it just reports
 on what it found, git-fsck itself is never "dangerous" to run.
 Running it while somebody is actually changing the repository can cause


@@ -3482,7 +3482,7 @@ You write your current index file to a "tree" object with the program
 $ git write-tree
 -------------------------------------------------
 
 $ git write-tree
 -------------------------------------------------
 

-that doesn't come with any options - it will just write out the
+that doesn't come with any options--it will just write out the

 current index into the set of tree objects that describe that state,
 and it will return the name of the resulting top-level tree. You can
 use that tree to re-generate the index at any time by going in the
 current index into the set of tree objects that describe that state,
 and it will return the name of the resulting top-level tree. You can
 use that tree to re-generate the index at any time by going in the


@@ -3493,7 +3493,7 @@ object database -> index
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 You read a "tree" file from the object database, and use that to
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 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
+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
 
 unsaved state that you might want to restore later!) your current
 index.  Normal operation is just
 


@@ -3541,7 +3541,7 @@ Tying it all together
 
 To commit a tree you have instantiated with "git-write-tree", you'd
 create a "commit" object that refers to that tree and the history
 
 To commit a tree you have instantiated with "git-write-tree", you'd
 create a "commit" object that refers to that tree and the history

-behind it - most notably the "parent" commits that preceded it in
+behind it--most notably the "parent" commits that preceded it in

 history.
 
 Normally a "commit" has one parent: the previous state of the tree
 history.
 
 Normally a "commit" has one parent: the previous state of the tree


@@ -3684,7 +3684,7 @@ 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
 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
+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).
 
 always do a merge against your last commit (which should thus match what
 you have in your current index anyway).
 


@@ -3956,7 +3956,7 @@ Two things are interesting here:
 
 - `get_sha1()` returns 0 on _success_.  This might surprise some new
   Git hackers, but there is a long tradition in UNIX to return different
 
 - `get_sha1()` returns 0 on _success_.  This might surprise some new
   Git hackers, but there is a long tradition in UNIX to return different

-  negative numbers in case of different errors -- and 0 on success.
+  negative numbers in case of different errors--and 0 on success.

 
 - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
   char \*`, but is actually expected to be a pointer to `unsigned
 
 - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
   char \*`, but is actually expected to be a pointer to `unsigned