X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=tour.mdwn;h=d07a469b3494e32b949a9e35cd5bd90db5e41b50;hb=076c9729b8e75773fdfe61befd348b5eb4ac10d4;hp=aa7fe709c143caa2fd0ad989a33bd549824b488d;hpb=c459dff0930d10fadd8a476a25cdc9e23e86593b;p=hgbook-git

diff --git a/tour.mdwn b/tour.mdwn
index aa7fe70..d07a469 100644
--- 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
-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.
@@ -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
-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
@@ -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
-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):
 
@@ -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
-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.
@@ -822,6 +822,16 @@ that tell me something that I can’t figure out with a quick glance at
 the output of "git log --stat" or “git log -p", (so repeating the list
 of all modified files is not useful, for example).
 
+To follow along with the example here, go ahead and type something
+like the following sentence into the editor. The misspelling here is
+intentional. You'll see how to fix that up after the fact in just a
+moment:
+
+	Fixed the typo so the program actuall complies now.
+
+Then save the file, and exit from the editor. When you do that, git
+will create the commit.
+
 #### 2.7.4 Aborting a commit
 
 If you decide that you don’t want to commit while in the middle of
@@ -869,13 +879,13 @@ identifier shown above. Can you do it?)
 So now that we've cloned a local repository, made a change to the
 code, setup our name and email address, and made a careful commit,
 we're just about ready to share our change with the world. But wait,
-that commit message has some really embarrassing misspellings in
-it. Wouldn't it be nice to touch those up before I post this commit
+that commit message has that embarrassing misspelling in
+it. Wouldn't it be nice to touch that up before we post this commit
 with a never-to-be-changed again commit identifier?
 
 This is the exact situation for which "git commit --amend" was
-invented. So I can just run that now and fix the broken commit
-message:
+invented. So you can just run that now and fix the broken commit
+message in the editor:
 
 	$ git commit --amend
 
@@ -935,9 +945,8 @@ helpful when the commit it isolates is as small as possible.
 
 One advantage of using git over some other systems is that the commit
 speed is blazingly fast. The tool doesn't punish you at all for
-committing as often as you get our project into a state that is worth
-saving. "Commit early, commit often" is a well-supported mode of
-operation with git.
+committing every time your project is in a state worth saving. "Commit
+early, commit often" is a well-supported mode of operation with git.
 
 ### 2.8 Sharing changes
 
@@ -986,7 +995,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.
 
-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
@@ -1016,7 +1025,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
-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.
 
@@ -1162,7 +1171,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
-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