Merge pull request #143 from tacker66/fix_some_typos

ben · ben · commit d8b780c0a68b · 2014-11-03T16:38:46.000-08:00
Fix some typos
diff --git a/README.asc b/README.asc
@@ -8,7 +8,7 @@ Like the first edition, the second edition of Pro Git is open source under a Cre
 
 A couple of things have changed since open sourcing the first edition. For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book. We've also moved to using O'Reilly's https://atlas.oreilly.com[Atlas platform] for generating continuous builds of the book so all major formats are always available in every language.
 
-We've also moved to keeping the translations in seperate repositories rather than subdirectories of the English repository. See the Translations section for more information.
+We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository. See the Translations section for more information.
 
 == Contributing
 
@@ -45,7 +45,7 @@ This uses the `asciidoctor`, `asciidoctor-pdf` and `asciidoctor-epub` projects.
 
 == Translations
 
-Translations to other languages are highly encouraged but handled a little differently than the first edition. We now keep each translation in a seperate repository and automatically build the output files through Atlas. This was something that was really difficult in the last edition.
+Translations to other languages are highly encouraged but handled a little differently than the first edition. We now keep each translation in a separate repository and automatically build the output files through Atlas. This was something that was really difficult in the last edition.
 
 Since each translation is a different repository, we can also have different maintainers for each project. The Pro Git team simply pulls them in and builds them for the translation teams. To get automatic builds, translations repositories will have to be under the https://github.com/progit[progit organization on GitHub].
 
diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc
@@ -60,7 +60,7 @@ $ htdigest -c /opt/git/.htpasswd "Git Access" schacon
 
 There are tons of ways to have Apache authenticate users, you'll have to choose and implement one of them. This is just the simplest example we could come up with. You'll also almost certainly want to set this up over SSL so all this data is encrypted.
 
-We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authenication needs. The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. You can do this with nearly any CGI-capable web server, so go with the one that you know best.
+We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs. The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. You can do this with nearly any CGI-capable web server, so go with the one that you know best.
 
 [NOTE]
 ====
diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc
@@ -42,7 +42,7 @@ From there, click the "`Add an SSH key`" button, give your key a name, paste the
 
 [NOTE]
 ====
-Be sure to name your SSH key something you can remember. You can name each of your keys (eg, "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for.
+Be sure to name your SSH key something you can remember. You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for.
 ====
 
 [[_personal_avatar]]
diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
@@ -270,7 +270,7 @@ image::images/mentions-02-render.png[PR references rendered]
 
 Notice that the full GitHub URL we put in there was shortened to just the information needed.
 
-Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superceded it. The link will look something like <<_pr_closed>>.
+Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <<_pr_closed>>.
 
 [[_pr_closed]]
 .Cross references rendered in a Pull Request.
diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc
@@ -60,7 +60,7 @@ Now that you have a project with some code in it and maybe even a few collaborat
 
 Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch.
 
-For these examples, let's assume you are ``tonychacon'' and you've created a new Arudino code project named ``fade''.
+For these examples, let's assume you are ``tonychacon'' and you've created a new Arduino code project named ``fade''.
 
 [[_email_notifications]]
 ===== Email Notifications
@@ -93,7 +93,7 @@ image::images/maint-03-email-resp.png[Email response]
 
 Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull <url> <branch>` syntax we saw earlier, or by adding the fork as a remote and fetching and merging.
 
-If the merge is trivial, you can also just hit the ``Merge'' buton on the GitHub site. This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link.
+If the merge is trivial, you can also just hit the ``Merge'' button on the GitHub site. This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link.
 
 [[_merge_button]]
 .Merge button and instructions for merging a Pull Request manually.
@@ -245,7 +245,7 @@ Web notifications only exist on GitHub and you can only check them on GitHub. If
 .Notification 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 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.
+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 notifications 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/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc
@@ -14,7 +14,7 @@ An organization is pretty easy to create; just click on the ``+'' icon at the to
 .The ``New organization'' menu item.
 image::images/neworg.png[The ``New organization'' menu item.]
 
-First you'll need to name your organzation and provide an email address for a main point of contact for the group. Then you can invite other users to be co-owners of the account if you want to.
+First you'll need to name your organization and provide an email address for a main point of contact for the group. Then you can invite other users to be co-owners of the account if you want to.
 
 Follow these steps and you'll soon be the owner of a brand-new organization.
 Like personal accounts, organizations are free if everything you plan to store there will be open source.
@@ -33,7 +33,7 @@ For example, say your company has three repositories: `frontend`, `backend`, and
 You'd want your HTML/CSS/Javascript developers to have access to `frontend` and maybe `backend`, and your Operations people to have access to `backend` and `deployscripts`.
 Teams make this easy, without having to manage the collaborators for every individual repository.
 
-The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organziation.
+The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organization.
 
 [[_org_page]]
 .The Organization page.
diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc
@@ -154,7 +154,7 @@ image::images/scripting-05-access-token.png[Access Token]
 
 It will ask you which scopes you want for this token and a description. Make sure to use a good description so you feel comfortable removing the token when your script or application is no longer used.
 
-GitHub will only show you the token once, so be sure to copy it. You can now use this to authenticate in your script instead of using a username and password. This is nice because you can limit the scope of what you want to do and the token is revokable.
+GitHub will only show you the token once, so be sure to copy it. You can now use this to authenticate in your script instead of using a username and password. This is nice because you can limit the scope of what you want to do and the token is revocable.
 
 This also has the added advantage of increasing your rate limit. Without authenticating, you will be limited to 60 requests per hour. If you authenticate you can make up to 5,000 requests per hour.
 
diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -145,7 +145,7 @@ What we really need to do is run the file we're trying to merge in through a `do
 
 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.
 
-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. Stage 1 is the common anecestor, stage 2 is your version and stage 3 is from the `MERGE_HEAD`, the version you're merging in (``theirs'').
+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. Stage 1 is the common ancestor, stage 2 is your version and stage 3 is from the `MERGE_HEAD`, the version you're merging in (``theirs'').
 
 You can extract a copy of each of these versions of the conflicted file with the `git show` command and a special syntax.
 
@@ -575,7 +575,7 @@ First of all, there is another useful thing we can do with the normal ``recursiv
 
 By default, when Git sees a conflict between two branches being merged, it will add merge conflict markers into your code and mark the file as conflicted and let you resolve it. If you would prefer for Git to simply choose a specific side and ignore the other side instead of letting you manually merge the conflict, you can pass the `merge` command either a `-Xours` or `-Xtheirs`.
 
-If Git sees this, it will not add conflict markers. Any differences that are mergable, it will merge. Any differences that conflict, it will simply choose the side you specify in whole, including binary files.
+If Git sees this, it will not add conflict markers. Any differences that are mergeable, it will merge. Any differences that conflict, it will simply choose the side you specify in whole, including binary files.
 
 If we go back to the ``hello world'' example we were using before, we can see that merging in our branch causes conflicts.
 
diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc
@@ -1,7 +1,7 @@
 [[_replace]]
 === Replace
 
-Git's objects are unchangable, but it does provide an interesting way to pretend to replace objects in it's database with other objects.
+Git's objects are unchangeable, but it does provide an interesting way to pretend to replace objects in it's database with other objects.
 
 The `replace` command lets you specify an object in Git and say "every time you see this, pretend it's this other thing". This is most commonly useful for replacing one commit in your history with another one.
 
diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc
@@ -148,7 +148,7 @@ It does up to three basic operations.
 
 The first thing `reset` will do is move what HEAD points to.
 This isn't the same as changing HEAD itself (which is what `checkout` does); `reset` moves the branch that HEAD is pointing to.
-This means if HEAD is set to the `master` branch (ie, you're currently on the `master` branch), running `git reset 9e5e64a` will start by making `master` point to `9e5e64a`.
+This means if HEAD is set to the `master` branch (i.e. you're currently on the `master` branch), running `git reset 9e5e64a` will start by making `master` point to `9e5e64a`.
 
 image::images/reset-soft.png[]
 
diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc
@@ -52,7 +52,7 @@ date.c:         if (gmtime_r(&time, tm)) {
 
 So here we can see that `gmtime_r` is called in the `match_multi_number` and `match_digit` functions in the date.c file.
 
-You can also look for complex combinations of strings with the `--and` flag, which makes sure that multiple matches are in the same line. For instance, let's look for any lines that define a contstant with either the strings ``LINK'' or ``BUF_MAX'' in them in the Git codebase in an older 1.8.0 version.
+You can also look for complex combinations of strings with the `--and` flag, which makes sure that multiple matches are in the same line. For instance, let's look for any lines that define a constant with either the strings ``LINK'' or ``BUF_MAX'' in them in the Git codebase in an older 1.8.0 version.
 
 Here we'll also use the `--break` and `--heading` options which help split up the output into a more readable format.
 
diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc
@@ -354,7 +354,7 @@ Git will by default try to update **all** of your submodules when you run `git s
 
 ===== Working on a Submodule
 
-It's quite likely that if you're using submodules, you're doing so because you really want to work on the code in the submodule at the same time as you're working on the code in the main project (or across several submodules). Otherwise you would probably instead be using a simpler dependency managment system (such as Maven or Rubygems).
+It's quite likely that if you're using submodules, you're doing so because you really want to work on the code in the submodule at the same time as you're working on the code in the main project (or across several submodules). Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems).
 
 So now let's go through an example of making changes to the submodule at the same time as the main project and committing and publishing those changes at the same time.
 
diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc
@@ -84,7 +84,7 @@ $ git config diff.word.textconv docx2txt
 Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.docx`, it should run those files through the ``word'' filter, which is defined as the `docx2txt` program.
 This effectively makes nice text-based versions of your Word files before attempting to diff them.
 
-Here's an example: Chapter 1 of this book was converted to Word format and commited in a Git repository.
+Here's an example: Chapter 1 of this book was converted to Word format and committed in a Git repository.
 Then a new paragraph was added.
 Here's what `git diff` shows:
 
diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc
@@ -63,7 +63,7 @@ You can override this in individual cases by starting the pathspec with `:(glob)
 *`GIT_ICASE_PATHSPECS`* sets all pathspecs to work in a case-insensitive manner.
 
 
-==== Commiting
+==== Committing
 
 The final creation of a Git commit object is usually done by `git-commit-tree`, which uses these environment variables as its primary source of information, falling back to configuration values only if these aren't present.
 
diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc
@@ -70,7 +70,7 @@ Each of them is tailored for a specific purpose (viewing history and creating co
 
 (((GitHub for Mac)))(((GitHub for Windows)))
 GitHub has created two workflow-oriented Git clients: one for Windows, and one for Mac.
-These clients are a good example of workflow-oriented tools – rathern than expose _all_ of Git's functionality, they instead focus on a curated set of commonly-used features that work well together.
+These clients are a good example of workflow-oriented tools – rather than expose _all_ of Git's functionality, they instead focus on a curated set of commonly-used features that work well together.
 They look like this:
 
 .GitHub for Mac.
diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc
@@ -183,7 +183,7 @@ Take a look at the `include/git2/sys/odb_backend.h` file in the Libgit2 source f
 ==== Other Bindings
 
 Libgit2 has bindings for many languages.
-Here we show a small example using a few of the more complete bindings pakages as of this writing; libraries exist for many other languages, including C++, Go, Node.js, Erlang, and the JVM, all in various stages of maturity.
+Here we show a small example using a few of the more complete bindings packages as of this writing; libraries exist for many other languages, including C++, Go, Node.js, Erlang, and the JVM, all in various stages of maturity.
 The official collection of bindings can be found by browsing the repositories at https://github.com/libgit2[].
 The code we'll write will return the commit message from the commit eventually pointed to by HEAD (sort of like `git log -1`).
 
diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc
@@ -12,7 +12,7 @@ There are two commands that are used quite a lot, from the first invocations of
 
 ==== git config
 
-Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This invovles everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories.
+Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This involves everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories.
 
 The `git config` command has been used in nearly every chapter of the book.
 
@@ -432,7 +432,7 @@ This command is covered in depth in <<_git_svn>>.
 
 For other version control systems or importing from nearly any format, you can use `git fast-import` to quickly map the other format to something Git can easily record.
 
-This command is coverd in depth in <<_custom_importer>>.
+This command is covered in depth in <<_custom_importer>>.
 
 === Administration
 
diff --git a/book/preface.asc b/book/preface.asc
