Fix minor issues

Author: Morganov

book/04-git-server/sections/hosted.asc

@@ -2,7 +2,7 @@
 
 If you don't want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site.
 Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved.
-Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with.
+Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code -- it's generally easier for the open source community to find and help you with.
 
 These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages.
 To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[].

book/06-github/sections/3-maintaining.asc

@@ -21,7 +21,7 @@ This takes you to the "`new repository`" form:
 image::images/newrepoform.png[The “new repository” form]
 
 All you really have to do here is provide a project name; the rest of the fields are completely optional.
-For now, just click the "`Create Repository`" button, and boom – you have a new repository on GitHub, named `<user>/<project_name>`.
+For now, just click the "`Create Repository`" button, and boom -- you have a new repository on GitHub, named `<user>/<project_name>`.
 
 Since you have no code there yet, GitHub will show you instructions for how to create a brand-new Git repository, or connect an existing Git project.
 We won't belabor this here; if you need a refresher, check out <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.

book/07-git-tools/sections/credentials.asc

@@ -4,7 +4,7 @@
 (((credentials)))
 (((git commands, credential)))
 If you use the SSH transport for connecting to remotes, it's possible for you to have a key without a passphrase, which allows you to securely transfer data without typing in your username and password.
-However, this isn't possible with the HTTP protocols – every connection needs a username and password.
+However, this isn't possible with the HTTP protocols -- every connection needs a username and password.
 This gets even harder for systems with two-factor authentication, where the token you use for a password is randomly generated and unpronounceable.
 
 Fortunately, Git has a credentials system that can help with this.

book/07-git-tools/sections/submodules.asc

@@ -415,7 +415,7 @@ Submodules changed but not updated:
 no changes added to commit (use "git add" and/or "git commit -a")
 ----
 
-By default, the  `git pull` command recursively fetches submodules changes, as we can see in the output of the first command above.
+By default, the `git pull` command recursively fetches submodules changes, as we can see in the output of the first command above.
 However, it does not *update* the submodules.
 This is shown by the output of the `git status` command, which shows the submodule is "`modified`", and has "`new commits`".
 What's more, the brackets showing the new commits point left (<), indicating that these commits are recorded in MainProject but are not present in the local DbConnector checkout.
@@ -500,7 +500,7 @@ Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5e
 ----
 
 If we go into the DbConnector directory, we have the new changes already merged into our local `stable` branch.
-Now let's see what happens when we make our own local change to the library and someone else pushes another change upstream at the same time.
+Now let's see what happens when we make our own local change to the library and someone else pushes another change to the upstream at the same time.
 
 [source,console]
 ----
@@ -608,7 +608,7 @@ to push them to a remote.
 
 As you can see, it also gives us some helpful advice on what we might want to do next.
 The simple option is to go into each submodule and manually push to the remotes to make sure they're externally available and then try this push again.
-If you want the check behavior to happen for all pushes, you can make this behavior the default by doing `git config push.recurseSubmodules check`.
+If you want the "`check`" behavior to happen for all pushes, you can make this behavior the default by doing `git config push.recurseSubmodules check`.
 
 The other option is to use the "`on-demand`" value, which will try to do this for you.
 
@@ -973,7 +973,7 @@ Indeed, if you switch between branches that record the submodule at different co
 That is because the submodule state is by default not carried over when switching branches.
 
 This can be really confusing, so it's a good idea to always `git checkout --recurse-submodules` when your project has submodules.
-For older Git versions that do not have the  `--recurse-submodules` flag, after the checkout you can use `git submodule update --init --recursive` to put the submodules in the right state.
+For older Git versions that do not have the `--recurse-submodules` flag, after the checkout you can use `git submodule update --init --recursive` to put the submodules in the right state.
 
 Luckily, you can tell Git (>=2.14) to always use the  `--recurse-submodules` flag by setting the configuration option `submodule.recurse`: `git config submodule.recurse true`.
 As noted above, this will also make Git recurse into submodules for every command that has a `--recurse-submodules` option (except `git clone`).
@@ -1008,7 +1008,7 @@ Checking connectivity... done.
 ----
 
 Now suppose you did that in a branch.
-If you try to switch back to a branch where those files are still in the actual tree rather than a submodule – you get this error:
+If you try to switch back to a branch where those files are still in the actual tree rather than a submodule -- you get this error:
 
 [source,console]
 ----

book/07-git-tools/sections/subtree-merges.asc

@@ -57,7 +57,7 @@ We just switched back to your `master` branch, and we pull the `rack_branch` bra
 $ git read-tree --prefix=rack/ -u rack_branch
 ----
 
-When we commit, it looks like we have all the Rack files under that subdirectory – as though we copied them in from a tarball.
+When we commit, it looks like we have all the Rack files under that subdirectory -- as though we copied them in from a tarball.
 What gets interesting is that we can fairly easily merge changes from one of the branches to the other.
 So, if the Rack project updates, we can pull in upstream changes by switching to that branch and pulling:
 
@@ -80,14 +80,14 @@ Automatic merge went well; stopped before committing as requested
 ----
 
 All the changes from the Rack project are merged in and ready to be committed locally.
-You can also do the opposite – make changes in the `rack` subdirectory of your `master` branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.
+You can also do the opposite -- make changes in the `rack` subdirectory of your `master` branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.
 
 This gives us a way to have a workflow somewhat similar to the submodule workflow without using submodules (which we will cover in <<ch07-git-tools#_git_submodules>>).
 We can keep branches with other related projects in our repository and subtree merge them into our project occasionally.
 It is nice in some ways, for example all the code is committed to a single place.
 However, it has other drawbacks in that it's a bit more complex and easier to make mistakes in reintegrating changes or accidentally pushing a branch into an unrelated repository.
 
-Another slightly weird thing is that to get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch – to see if you need to merge them – you can't use the normal `diff` command.
+Another slightly weird thing is that to get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch -- to see if you need to merge them -- you can't use the normal `diff` command.
 Instead, you must run `git diff-tree` with the branch you want to compare to:
 
 [source,console]