docs: more proofing

Author: dwmkerr

docs/05-building-your-toolkit/26-managing-your-dotfiles/index.md

@@ -36,7 +36,7 @@ You will mostly see dotfiles in your `HOME` directory. They have a dot to mark t
 
 As an example, a user's personal Bash configuration is stored in _~/.bashrc_, but the global Bash configuration applied to _all_ users is stored in _/etc/bash.bashrc_. The second configuration file does not need a dot in front of it - the _/etc_ folder is where configuration is kept so there is no need to differentiate it from other files like a user's personal files.
 
-Nowadays, when a user say "my dotfiles", they typically mean their _configuration_ files that are kept in their home directory. In a sense, your dotfiles are a bit like your personal settings for your computer. On a desktop environment your settings might be things like your theme or wallpaper. For a shell user, you settings will be files like _~/.bashrc_ for your shell configuration, _~/.ssh/config_ for your SSH configuration and so on.
+Nowadays, when a user says "my dotfiles", they typically mean their _configuration_ files that are kept in their home directory. In a sense, your dotfiles are a bit like your personal settings for your computer. On a desktop environment your settings might be things like your theme or wallpaper. For a shell user, you settings will be files like _~/.bashrc_ for your shell configuration, _~/.ssh/config_ for your SSH configuration and so on.
 
 You will likely change the dotfiles over time to suit your preferences. Let's take a look at some sensible ways to organise and structure your dotfiles so that you can easily see what is your personal configuration, rather than what is the default configuration provided by the system, and easily manage these configurations.
 
@@ -201,7 +201,7 @@ VISUAL=nano
 EDITOR=nano
 ```
 
-There are two variables are are used by the shell and command line programs to run an editor. The first, and original, variable was `EDITOR`. This was originally often a _line mode_ editor - i.e. a text editor that doesn't take up the whole screen. This was useful in the days of printed output, before screens were used. The `VISUAL` variable was used to specify the editor that could be used for 'full screen' terminal editing. Some programs use `EDITOR` and some use `VISUAL` so it is best to set both.
+There are two variables are used by the shell and command line programs to run an editor. The first, and original, variable was `EDITOR`. This was originally often a _line mode_ editor - i.e. a text editor that doesn't take up the whole screen. This was useful in the days of printed output, before screens were used. The `VISUAL` variable was used to specify the editor that could be used for 'full screen' terminal editing. Some programs use `EDITOR` and some use `VISUAL` so it is best to set both.
 
 I have used the `nano` editor in this example as it available on many distributions and is a little easier than `vi` or `emacs`, but you can use whatever you like. For my personal dotfiles I use `vi`.
 
@@ -330,7 +330,7 @@ This is a great way to verify that the script works as expected, before we actua
 
 Now that we have a working shell dotfile, we can source it as part of our shell startup.
 
-Rather than having our shell startup file know about our _~/dotfiles_ folder, we will create a symlink to th shell script from our home directory:
+Rather than having our shell startup file know about our _~/dotfiles_ folder, we will create a symlink to the shell script from our home directory:
 
 Finally, we can create a symlink in our home directory that points to our _~/dotfiles/shell.sh_ file and we are good to go!
 

docs/05-building-your-toolkit/27-controlling-changes-with-git/index.md

@@ -89,7 +89,7 @@ nothing added to commit but untracked files present (use "git add" to track)
 
 The first thing that `git status` tells us is the name of the _branch_ we are on. We'll look at branches in detail shortly. The next thing we see is that there are no _commits_ - commits are sets of changes that we track. Finally, git is telling us that there are three files that are 'untracked'. These are the _install.sh_ and _shell.sh_ files as well as the _shell.d_ folder.
 
-If we are going to use Git to track changes to these file, we need to add them to the repository. We can do that with the _git add_ (_add file contents to index_) command<!--index-->:
+If we are going to use Git to track changes to these files, we need to add them to the repository. We can do that with the _git add_ (_add file contents to index_) command<!--index-->:
 
 ```
 $ git add .
@@ -329,7 +329,7 @@ $ tree
 └── shell.sh
 ```
 
-When we switch back to the _main_ branch and look our our working tree we can see that the _git_aliases.sh_ file is not present. This is very cool - by passing the name of the branch we want to switch to as the parameter to the `git checkout` command we can switch branches. If we are on the _main_ branch we don't see the _git_aliases.sh_ file, because the commit that added is was not on the _main_ branch. To go back to the _aliases_ branch we can just checkout again:
+When we switch back to the _main_ branch and look at our working tree we can see that the _git_aliases.sh_ file is not present. This is very cool - by passing the name of the branch we want to switch to as the parameter to the `git checkout` command we can switch branches. If we are on the _main_ branch we don't see the _git_aliases.sh_ file, because the commit that added is was not on the _main_ branch. To go back to the _aliases_ branch we can just checkout again:
 
 ```
 $ git checkout aliases
@@ -902,4 +902,4 @@ We've introduced a lot of commands in this chapter - you can use this table as a
 | `git mv <source> <destination>` | Stage the movement of `source` to `destination`.                                            |
 | `git checkout 8342bec`          | Checkout a commit with SHA `834bec`.                                                        |
 | `git checkout HEAD~1`           | Move the current HEAD back one commit.                                                      |
-| `git checkout <branch>~3`       | Checkout `branch`, move back three commits from the tip.                                    |
+| `git checkout <branch>~3`       | Checkout `branch`, move back three commits from the tip.                                    |

docs/05-building-your-toolkit/28-managing-remote-git-repositories/index.md

@@ -257,7 +257,7 @@ Choose the 'fork' option and GitHub will create a copy of the repository in your
 
 If you have made changes to a fork, you can then open a _Pull Request_. A pull request is a request to merge a set of changes from one branch into another, or from one fork into the original repository. So if you were to improve upon the dotfiles that you forked, and wanted to share your changes back, you could open a pull request to do so.
 
-Typically when a pull request is opened, the project maintainer will then review the changes, make suggestions or discuss the proposal, and then either merge the pull request or reject it. In the screenshot below I am opening a pull request from my clone of the dorfile repository to the original dotfiles repository, this pull requests adds an uninstall script to the repository. A maintainer of the target repository will then review the changes:
+Typically when a pull request is opened, the project maintainer will then review the changes, make suggestions or discuss the proposal, and then either merge the pull request or reject it. In the screenshot below I am opening a pull request from my clone of the dotfiles repository to the original dotfiles repository, this pull requests adds an uninstall script to the repository. A maintainer of the target repository will then review the changes:
 
 ![Screenshot of a pull request being opened](./images/github-open-pull-request.png)
 
@@ -447,4 +447,4 @@ In this chapter we learned how to use GitHub to host a remote repository, how to
 
 Although we've only scratched the surface of what Git can do, you should now have the tools to work with repositories, share content like your dotfiles, collaborate with others and manage your own changes.
 
-In the next part of the book we will look at some advanced techniques that can help you as a shell user.
+In the next part of the book we will look at some advanced techniques that can help you as a shell user.