Merge pull request #405 from Lazar95/whitespace-errors

remove unneeded double whitespaces

Author: ben

book/06-github/sections/2-contributing.asc

@@ -32,7 +32,7 @@ After a few seconds, you'll be taken to your new project page, with your own wri
 (((GitHub, Flow)))
 GitHub is designed around a particular collaboration workflow, centered on Pull Requests.
 This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks.
-It is centered on the <<_topic_branch>> workflow covered  in <<_git_branching>>.
+It is centered on the <<_topic_branch>> workflow covered in <<_git_branching>>.
 
 Here's how it generally works:
 

book/07-git-tools/sections/advanced-merging.asc

@@ -165,7 +165,7 @@ So how would we do that?
 
 First, we get into the merge conflict state.
 Then we want to get copies of my version of the file, their version (from the branch we're merging in) and the common version (from where both sides branched off).
-Then we want to fix up either their side or our side and re-try the merge again  for just this single file.
+Then we want to fix up either their side or our side and re-try the merge again for just this single file.
 
 Getting the three file versions is actually pretty easy.
 Git stores all of these versions in the index under ``stages'' which each have numbers associated with them.
@@ -422,7 +422,7 @@ $ git log --oneline --left-right HEAD...MERGE_HEAD
 That's a nice list of the six total commits involved, as well as which line of development each commit was on.
 
 We can further simplify this though to give us much more specific context.
-If we add the `--merge` option to `git log`, it will only show the commits in either side of the  merge that touch a file that's currently conflicted.
+If we add the `--merge` option to `git log`, it will only show the commits in either side of the merge that touch a file that's currently conflicted.
 
 [source,console]
 ----

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

@@ -269,7 +269,7 @@ Like `reset`, `checkout` manipulates the three trees, and it is a bit different
 Running `git checkout [branch]` is pretty similar to running `git reset --hard [branch]` in that it updates all three trees for you to look like `[branch]`, but there are two important differences.
 
 First, unlike `reset --hard`, `checkout` is working-directory safe; it will check to make sure it's not blowing away files that have changes to them.
-Actually, it's a bit smarter than that – it tries to do a trivial merge in the Working Directory, so all of the files you _haven't_ changed in  will be updated.
+Actually, it's a bit smarter than that – it tries to do a trivial merge in the Working Directory, so all of the files you _haven't_ changed in will be updated.
 `reset --hard`, on the other hand, will simply replace everything across the board without checking.
 
 The second important difference is how it updates HEAD.

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

@@ -157,7 +157,7 @@ a11bef0 N Scott Chacon  first commit
 
 Here we can see that only the latest commit is signed and valid and the previous commits are not.
 
-In Git 1.8.3 and later, "git merge" and "git pull" can  be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the `--verify-signatures` command.
+In Git 1.8.3 and later, "git merge" and "git pull" can be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the `--verify-signatures` command.
 
 If you use this option when merging a branch and it contains commits that are not signed and valid, the merge will not work.
 

book/10-git-internals/sections/refs.asc

@@ -27,7 +27,7 @@ Now, you can use the head reference you just created instead of the SHA-1 value
 
 [source,console]
 ----
-$ git log --pretty=oneline  master
+$ git log --pretty=oneline master
 1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
 cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit

book/C-git-commands/1-git-commands.asc

@@ -54,7 +54,7 @@ We first introduce this in <<_getting_a_repo>>, where we show creating a brand n
 
 We talk briefly about how you can change the default branch from ``master'' in <<_remote_branches>>.
 
-We use this command to create an empty bare  repository for a server in <<_bare_repo>>.
+We use this command to create an empty bare repository for a server in <<_bare_repo>>.
 
 Finally, we go through some of the details of what it actually does behind the scenes in <<_plumbing_porcelain>>.
 
@@ -194,7 +194,7 @@ Finally, we go through some of what it does in the background in <<_git_refs>>.
 
 ==== git checkout
 
-The `git checkout` command is used to switch branches and  check content out into your working directory.
+The `git checkout` command is used to switch branches and check content out into your working directory.
 
 We first encounter the command in <<_switching_branches>> along with the `git branch` command.
 
@@ -208,7 +208,7 @@ Finally, we go into some implementation detail in <<_the_head>>.
 
 ==== git merge
 
-The `git merge` tool is used to merge one or more branches  into the branch you have checked out.
+The `git merge` tool is used to merge one or more branches into the branch you have checked out.
 It will then advance the current branch to the result of the merge.
 
 The `git merge` command was first introduced in <<_basic_branching>>.