🎶 Heal the words

pborreli · pborreli · commit 294bfed8db4a · 2014-10-28T11:25:30.000Z
diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc
@@ -4,7 +4,7 @@ There are a lot of different ways to use Git.
 There are the original command line tools, and there are many graphical user interfaces of varying capabilities.
 For this book, we will be using Git on the command line.
 For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity.
-If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not neccesarily true.
+If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true.
 Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
 
 So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.
diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc
@@ -85,7 +85,7 @@ If you didn't want it to be called `serverfix` on the remote, you could instead
 ====
 If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push.
 
-If you don't want to type it every sinlge time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few mintues, which you can easily set up by running `git config --global credential.helper cache`.
+If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few mintues, which you can easily set up by running `git config --global credential.helper cache`.
 
 For more information on the various credential caching options available, see <<_credential_caching>>.
 ====
diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc
@@ -4,7 +4,7 @@
 GitWeb is pretty simplistic though.
 If you're looking for a more modern, fully featured Git server, there are some several open source solutions out there that you can install instead.
 As GitLab is one of the more popular ones, we'll cover installing and using it as an example.
-This is a bit more complex than the GitWeb option and likely requires more maintainance, but it is a much more fully featured option.
+This is a bit more complex than the GitWeb option and likely requires more maintenance, but it is a much more fully featured option.
 
 ==== Installation
 
diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
@@ -146,7 +146,7 @@ image::images/blink-04-email.png[Email notification]
 Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.
 
 [[_pr_discussion]]
-.Pull Request discusson page
+.Pull Request discussion page
 image::images/blink-05-general-comment.png[PR discussion page]
 
 Now the contributor can see what they need to do in order to get their change accepted. Luckily this is also a very simple thing to do. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push.
@@ -168,7 +168,7 @@ This is the basic workflow that most GitHub projects use. Topic branches are cre
 [NOTE]
 .Not Only Forks
 ====
-It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking neccesary.
+It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking necessary.
 ====
 
 ==== Advanced Pull Requests
@@ -237,7 +237,7 @@ To https://github.com/tonychacon/blink
 <1> Add the original repository as a remote named ``upstream''
 <2> Fetch the newest work from that remote
 <3> Merge the main branch into your topic branch
-<4> Fix the conflict that occured
+<4> Fix the conflict that occurred
 <5> Push back up to the same topic branch
 
 Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly.
@@ -395,7 +395,7 @@ Not that this is incredibly useful, but it does add an element of fun and emotio
 
 [NOTE]
 ====
-There are actually quite a number of web services that make use of emoji charaters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:
+There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:
 
 http://www.emoji-cheat-sheet.com
 ====
diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc
@@ -233,19 +233,19 @@ When we mention ``notifications'' here with respect to GitHub, we mean a specifi
 If you go to the ``Notification center'' tab from the settings page, you can see some of the options you have.
 
 .Notification center options.
-image::images/maint-07-notifications.png[Notifiation center]
+image::images/maint-07-notifications.png[Notification center]
 
-The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, niether or both for when you actively participate in things and for activity on repositories you are watching.
+The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching.
 
 ====== Web Notifications
 
 Web notifications only exist on GitHub and you can only check them on GitHub. If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>.
 
 [[_not_center]]
 .Notification center.
-image::images/maint-08-notifications-page.png[Notifiation center]
+image::images/maint-08-notifications-page.png[Notification center]
 
-If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notifiction by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifictions in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
+If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifictions in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
 
 All of these tools are very useful for handling large numbers of notifications. Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen.
 
diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -1,7 +1,7 @@
 [[_advanced_merging]]
 === Advanced Merging
 
-Merging in Git is typically fairly easy. Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be suprised by one enormous conflict at the end of the series.
+Merging in Git is typically fairly easy. Since Git makes it easy to merge another branch multiple times, it means that you can have a very long lived branch but you can keep it up to date as you go, solving small conflicts often, rather than be surprised by one enormous conflict at the end of the series.
 
 However, sometimes tricky conflicts do occur. Unlike some other version control systems, Git does not try to be overly clever about merge conflict resolution. Git's philosophy is to be smart about determining when a merge resolution is unambiguous, but if there is a conflict, it does not try to be clever about automatically resolving it. Therefore, if you wait too long to merge two branches that diverge quickly, you can run into some issues.
 
diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc
@@ -93,7 +93,7 @@ Total 9 (delta 0), reused 0 (delta 0)
 
 Now we have a `commits.bundle` file in our directory. If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime.
 
-When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository.  The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the neccesary ancestors to reconstitute it properly.
+When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository.  The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the necessary ancestors to reconstitute it properly.
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc
@@ -184,4 +184,4 @@ e146b5f14e79d4935160c0e83fb9ebe526b8da0d commit	refs/remotes/origin/master
 c6e1e95051d41771a649f3145423f8809d1a74d4 commit	refs/replace/81a708dd0e167a3f691541c7a6463343bc457040
 ----
 
-This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it.  This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why seperate them?) but it can be useful in other circumstances.
+This means that it's easy to share our replacement with others, because we can push this to our server and other people can easily download it.  This is not that helpful in the history grafting scenario we've gone over here (since everyone would be downloading both histories anyhow, so why separate them?) but it can be useful in other circumstances.
diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc
@@ -178,7 +178,7 @@ Fast-forward
  1 file changed, 2 insertions(+)
 ----
 
-You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and futhermore signs the resulting merge commit.
+You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and furthermore signs the resulting merge commit.
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc
@@ -212,7 +212,7 @@ Finally, you may not want to stash some work or files in your working directory,
 
 Some common reasons for this might be to remove cruft that has been generated by merges or external tools or to remove build artifacts in order to run a clean build.
 
-You'll want to be pretty careful with this command, since it's designed to remove files from your working directory that are not tracked. If you change your mind, there is often no retreiving the content of those files. A safer option is to run `git stash --all` to remove everything but save it in a stash.
+You'll want to be pretty careful with this command, since it's designed to remove files from your working directory that are not tracked. If you change your mind, there is often no retrieving the content of those files. A safer option is to run `git stash --all` to remove everything but save it in a stash.
 
 Assuming you do want to remove cruft files or clean your working directory, you can do so with `git clean`. To remove all the untracked files in your working directory, you can run `git clean -f -d`, which removes any files and also any subdirectories that become empty as a result. The `-f` means 'force' or "really do this".
 
diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc
@@ -463,7 +463,7 @@ Submodule DbConnector c87d55d..82d2ad3:
   > Merge from origin/stable
   > updated setup script
   > unicode support
-  > remove unnessesary method
+  > remove unnecessary method
   > add new option for conn pooling
 ----
 
@@ -843,6 +843,6 @@ Switched to branch 'master'
 
 Then, when you switch back, you get an empty `CryptoLibrary` directory for some reason and `git submodule update` may not fix it either. You may need to go into your submodule directory and run a `git checkout .` to get all your files back. You could run this in a `submodule foreach` script to run it for multiple submodules.
 
-It's important to note that submodules these days keep all their Git data in the top project's `.git` directory, so unlike much older versions of Git, destorying a submodule directory won't lose any commits or branches that you had.
+It's important to note that submodules these days keep all their Git data in the top project's `.git` directory, so unlike much older versions of Git, destroying a submodule directory won't lose any commits or branches that you had.
 
 With these tools, submodules can be a fairly simple and effective method for developing on several related but still separate projects simultaneously.
diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc
@@ -4,7 +4,7 @@
 The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one and vice versa.
 When you specify a subtree merge, Git is often smart enough to figure out that one is a subtree of the other and merge appropriately.
 
-We'll go through an example of adding a seperate project into an existing project and then merging the code of the second into a subdirectory of the first.
+We'll go through an example of adding a separate project into an existing project and then merging the code of the second into a subdirectory of the first.
 
 First, we'll add the Rack application to our project.
 We'll add the Rack project as a remote reference in our own project and then check it out into its own branch:
diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc
@@ -2,7 +2,7 @@
 ==== TFS
 
 (((TFS)))(((Importing, from TFS)))
-If your team is convering their source control from TFVC to Git, you'll want the highest-fidelity conversion you can get.
+If your team is converting their source control from TFVC to Git, you'll want the highest-fidelity conversion you can get.
 This means that, while we covered both git-tfs and git-tf for the interop section, we'll only be covering git-tfs for this part, because git-tfs supports branches, and this is prohibitively difficult using git-tf.
 
 [NOTE]
diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc
@@ -2,7 +2,7 @@
 
 (((Eclipse)))
 Eclipse ships with a plugin called Egit, which provides a fairly-complete interface to Git operations.
-It's accessed by switching to the Git Perspective (Window > Open Perpective > Other…, and select "Git").
+It's accessed by switching to the Git Perspective (Window > Open Perspective > Other…, and select "Git").
 
 .Eclipse's EGit environment.
 image::images/egit.png[Eclipse's EGit environment.]
diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc
@@ -4,7 +4,7 @@
 (((powershell)))(((tab completion, powershell)))(((shell prompts, powershell)))
 (((posh-git)))
 The standard command-line terminal on Windows (`cmd.exe`) isn't really capable of a customized Git experience, but if you're using Powershell, you're in luck.
-A package called Posh-Git (https://github.com/dahlbyk/posh-git[]) provides powerful tab-completion facilities, as well as an enhanced prompt to help you stay on top of your repostitory status. It looks like this:
+A package called Posh-Git (https://github.com/dahlbyk/posh-git[]) provides powerful tab-completion facilities, as well as an enhanced prompt to help you stay on top of your repository status. It looks like this:
 
 .Powershell with Posh-git.
 image::images/posh-git.png[Powershell with Posh-git.]
diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc
@@ -114,7 +114,7 @@ We only briefly mention this in <<_git_difftool>>.
 
 ==== git commit
 
-The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanant snapshot in the database and then moves the branch pointer on the current branch up to it.
+The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it.
 
 We first cover the basics of committing in <<_committing_changes>>. There we also demonstrate how to use the `-a` flag to skip the `git add` step in daily workflows and how to use the `-m` flag to pass a commit message in on the command line instead of firing up an editor.
 
@@ -146,7 +146,7 @@ The only other differing use of `git rm` in the book is in <<_removing_objects>>
 
 ==== git mv
 
-The `git mv` command is a thin convience command to move a file and then run `git add` on the new file and `git rm` on the old file.
+The `git mv` command is a thin convenience command to move a file and then run `git add` on the new file and `git rm` on the old file.
 
 We only briefly mention this command in <<_git_mv>>.
 
@@ -226,13 +226,13 @@ In <<_signing_commits>> we see how to use `--show-signature` to add a validation
 
 ==== git stash
 
-The `git stash` command is used to temporarily store uncomitted work in order to clean out your working directory without having to commit unfinished work on a branch.
+The `git stash` command is used to temporarily store uncommitted work in order to clean out your working directory without having to commit unfinished work on a branch.
 
 This is basically entirely covered in <<_git_stashing>>.
 
 ==== git tag
 
-The `git tag` command is used to give a permanant bookmark to a specific point in the code history. Generally this is used for things like releases.
+The `git tag` command is used to give a permanent bookmark to a specific point in the code history. Generally this is used for things like releases.
 
 This command is introduced and covered in detail in <<_git_tagging>> and we use it in practice in <<_tagging_releases>>.
 
@@ -368,7 +368,7 @@ The `git rebase` command is basically an automated `cherry-pick`. It determines
 
 Rebasing is covered in detail in <<_rebasing>>, including covering the collaborative issues involved with rebasing branches that are already public.
 
-We use it in practice during an example of splitting your history into two seperate repositories in <<_replace>>, using the `--onto` flag as well.
+We use it in practice during an example of splitting your history into two separate repositories in <<_replace>>, using the `--onto` flag as well.
 
 We go through running into a merge conflict during rebasing in <<_rerere>>.
 
