Fix several typos

diff --git a/tour.mdwn b/tour.mdwn
index aa7fe709c143caa2fd0ad989a33bd549824b488d..85ebedd27070584083899d8f01c9a1f77a0d1783 100644 (file)
--- a/tour.mdwn
+++ b/tour.mdwn
@@ -318,7 +318,7 @@ The default fields in a record of output from “git log” are as follows.
 The output of the "git log" command can be made more or less verbose
 by means of the --pretty option. For example, with "git log
 --pretty=short" the commit identifier will be omitted and only the
 The output of the "git log" command can be made more or less verbose
 by means of the --pretty option. For example, with "git log
 --pretty=short" the commit identifier will be omitted and only the

-first line of each commit message will be show. And with "git log
+first line of each commit message will be shown. And with "git log

 --pretty=fuller", (the name 'fuller' is in contrast to the default
 --pretty=full), the committer name and dates will be printed in
 addition to the author name and dates.
 --pretty=fuller", (the name 'fuller' is in contrast to the default
 --pretty=full), the committer name and dates will be printed in
 addition to the author name and dates.


@@ -349,8 +349,8 @@ So there are places where it is often important to archive the
 complete commit identifier, (perhaps in bug-tracking systems to
 indicate a specific commit that fixes a bug, for example). But often,
 in more casual settings, it's more convenient to use abbreviated
 complete commit identifier, (perhaps in bug-tracking systems to
 indicate a specific commit that fixes a bug, for example). But often,
 in more casual settings, it's more convenient to use abbreviated

-commit identifiers. Git accept any unique prefix of a commit
-identifier, (and for reasonably-sized project the first 8 or 10
+commit identifiers. Git accepts any unique prefix of a commit
+identifier, (and for reasonably-sized projects the first 8 or 10

 characters are almost always unique).
 
 And unlike the permanent commit identifiers, git also provides
 characters are almost always unique).
 
 And unlike the permanent commit identifiers, git also provides


@@ -469,7 +469,7 @@ of the change, such as the "diffstat" information with --stat:
 
 Or perhaps you'd like to see the actual patch content of each change,
 which you can get with -p. That commit with the word typo in its name
 
 Or perhaps you'd like to see the actual patch content of each change,
 which you can get with -p. That commit with the word typo in its name

-looks suspicous, so let's tak a closer look. Remember that we can name
+looks suspicious, so let's take a closer look. Remember that we can name

 it as master~3, HEAD~3, or any prefix of its commit identifier, (such
 as 13ed136b):
 
 it as master~3, HEAD~3, or any prefix of its commit identifier, (such
 as 13ed136b):
 


@@ -793,7 +793,7 @@ deleting these lines has no effect.
 #### 2.7.3 Writing a good commit message
 
 A good commit message will generally have a single line that
 #### 2.7.3 Writing a good commit message
 
 A good commit message will generally have a single line that

-summarizes the commit, a blank line, and then one or more pargraphs
+summarizes the commit, a blank line, and then one or more paragraphs

 with supporting detail. Since many tools only print the first line of
 a commit message by default, it’s important that the first line stands
 alone.
 with supporting detail. Since many tools only print the first line of
 a commit message by default, it’s important that the first line stands
 alone.


@@ -986,7 +986,7 @@ even be able to understand that. I think it would be ideal if all of
 the progress-tracking spew were reduced to a single line. Something
 like "Computing (100%) Transferring (100%)" or whatever.
 
 the progress-tracking spew were reduced to a single line. Something
 like "Computing (100%) Transferring (100%)" or whatever.
 

-After (lots!) of progresss indication, git gives a report of which
+After (lots!) of progress indication, git gives a report of which

 files were modified, (which is very useful for getting a quick feel
 for what happened). If you would like more details on what changes
 came in, git provides a range that is perfect for examining. Let's
 files were modified, (which is very useful for getting a quick feel
 for what happened). If you would like more details on what changes
 came in, git provides a range that is perfect for examining. Let's


@@ -1016,7 +1016,7 @@ automatically update the working-directory files as necessary.
 Sometimes you may not know if you want to pull in the changes from the
 remote repository or not. It's useful to be able to examine them
 before accepting them into our branch. The "git pull" command shown in
 Sometimes you may not know if you want to pull in the changes from the
 remote repository or not. It's useful to be able to examine them
 before accepting them into our branch. The "git pull" command shown in

-the previous section is conceptually the combination of two command,
+the previous section is conceptually the combination of two commands,

 "git fetch" and "git merge". We can use these commands separately to
 examine the change before accepting it.
 
 "git fetch" and "git merge". We can use these commands separately to
 examine the change before accepting it.
 


@@ -1162,7 +1162,7 @@ We can also list all known remote-tracking branches with "git branch
 These remote-tracking branches make it very easy to collaborate with
 people as they are working on experimental features not yet ready for
 upstream inclusion. For example, if fred's latest code is still
 These remote-tracking branches make it very easy to collaborate with
 people as they are working on experimental features not yet ready for
 upstream inclusion. For example, if fred's latest code is still

-trashing filesystems then he might not want to push it out the the
+trashing filesystems then he might not want to push it out to the

 project's primary repository. But he may still want my help with
 it. So he can push it to a branch in his own repository for which I've
 got a remote. Then on my next "git fetch fred" I might notice a new
 project's primary repository. But he may still want my help with
 it. So he can push it to a branch in his own repository for which I've
 got a remote. Then on my next "git fetch fred" I might notice a new