Minor edits to Introduction section of book (01 through 03 in source)

Charlie O'Keefe · Charlie O'Keefe · commit 23561c6c92fc · 2008-08-11T22:09:17.000-06:00
diff --git a/text/01_Introduction/0_ Introduction.markdown b/text/01_Introduction/0_ Introduction.markdown
@@ -18,16 +18,16 @@ minutes to read through.
 Next we will go over **Intermediate Git Usage** - things that are slightly more
 complex, but may replace some of the basic commands you learned in the first 
 section.  This will mostly be tricks and commands that will feel more 
-comforatble after you know the basic commands.
+comfortable after you know the basic commands.
 
 After you have all of that mastered, we will cover **Advanced Git** - commands
 that most people probably don't use very often, but can be very helpful in
 certain situations.  Learning these commands should round out your day-to-day
-git knowledge, you will be a master of the Git.
+git knowledge; you will be a master of the Git!
 
 Now that you know Git, we will then cover **Working with Git**.  Here we will go
 over how to use Git in scripts, with deployment tools, with editors and more.
-These sections are meant to help you integrate Git into your environement.
+These sections are meant to help you integrate Git into your environment.
 
 Lastly, we will have a series of articles on **low-level documentation** that may
 help the Git hackers who want to learn how the actual internals and protocols
diff --git a/text/02_Git_Object_Db_Basics/0_ Git_Object_Db_Basics.markdown b/text/02_Git_Object_Db_Basics/0_ Git_Object_Db_Basics.markdown
@@ -11,7 +11,7 @@ looks something like this:
 You will see these 40-character strings all over the place in Git.
 In each case the name is calculated by taking the SHA1 hash of the
 contents of the object.  The SHA1 hash is a cryptographic hash function.
-What that means to us is that it is impossible to find two different
+What that means to us is that it is virtually impossible to find two different
 objects with the same name.  This has a number of advantages; among
 others:
 
@@ -32,7 +32,7 @@ type of object it is, and there are four different types of objects:
 
 - A **"blob"** is used to store file data - it is generally a file.
 - A **"tree"** is basically like a directory - it references a bunch of
-    other trees and/or blobs (ie. files and sub-directories)
+    other trees and/or blobs (i.e. files and sub-directories)
 - A **"commit"** points to a single tree, marking it as what the project
     looked like at a certain point in time.  It contains meta-information
     about that point in time, such as a timestamp, the author of the changes
@@ -42,14 +42,10 @@ type of object it is, and there are four different types of objects:
     along those lines.
 
 Almost all of Git is built around manipulating this simple structure of four
-different object types.  It is sort of it's own little filesystem that sits
-on top of your filesystem.
+different object types.  It is sort of its own little filesystem that sits
+on top of your machine's filesystem.
 
 ### Different from SVN ###
 
 It is important to note that this is very different from most SCM systems
-that you are probably used to.  Subversion, CVS, Perforce, Mercurial and the like all 
-use _Delta Storage_ systems - they store the differences between one commit
-and the next.  Git does not do this - it stores a snapshot of what all the
-files in your project look like each time you commit in this tree structure. This 
-is a very important concept to understand when using Git.
+that you may be familiar with.  Subversion, CVS, Perforce, Mercurial and the like all use _Delta Storage_ systems - they store the differences between one commit and the next.  Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git.
diff --git a/text/02_Git_Object_Db_Basics/1_Trees_and_Blobs.markdown b/text/02_Git_Object_Db_Basics/1_Trees_and_Blobs.markdown
@@ -5,7 +5,7 @@ A blob generally stores the contents of a file.
 [fig:object-blob]
 
 You can use linkgit:git-show[1] to examine the contents of any blob. 
-Assuming we have a SHA for a blob, we can examine its contents like this:
+Assuming we have the SHA for a blob, we can examine its contents like this:
 
     $ git show 6ff87c4664
 
@@ -14,7 +14,7 @@ Assuming we have a SHA for a blob, we can examine its contents like this:
      v2.2 or v3.x or whatever), unless explicitly otherwise stated.
     ...
 
-A "blob" object is nothing but a binary blob of data.  It doesn't refer
+A "blob" object is nothing but a chunk of binary data.  It doesn't refer
 to anything else or have attributes of any kind, not even a file name.
 
 Since the blob is entirely defined by its data, if two files in a
@@ -32,7 +32,7 @@ trees - it generally represents the contents of a directory or subdirectory.
 
 The ever-versatile linkgit:git-show[1] command can also be used to
 examine tree objects, but linkgit:git-ls-tree[1] will give you more
-details.  Assuming we have a SHA for a tree, we can examine it like this:
+details.  Assuming we have the SHA for a tree, we can examine it like this:
 
     $ git ls-tree fb3a8bdd0ce
     100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
@@ -49,9 +49,7 @@ As you can see, a tree object contains a list of entries, each with a
 mode, object type, SHA1 name, and name, sorted by name.  It represents
 the contents of a single directory tree.
 
-The object type may be a blob, representing the contents of a file, or
-another tree, representing the contents of a subdirectory.  Since trees
-and blobs, like all other objects, are named by the SHA1 hash of their
+An object referenced by a tree may be blob, representing the contents of a file, or another tree, representing the contents of a subdirectory.  Since trees and blobs, like all other objects, are named by the SHA1 hash of their
 contents, two trees have the same SHA1 name if and only if their
 contents (including, recursively, the contents of all subdirectories)
 are identical.  This allows git to quickly determine the differences
diff --git a/text/02_Git_Object_Db_Basics/2_Commits.markdown b/text/02_Git_Object_Db_Basics/2_Commits.markdown
@@ -34,9 +34,9 @@ As you can see, a commit is defined by:
 - an **author**: The name of the person responsible for this change, together
   with its date.
 - a **committer**: The name of the person who actually created the commit,
-  with the date it was done.  This may be different from the author, for
-  example, if the author was someone who wrote a patch and emailed it
-  to the person who used it to create the commit.
+  with the date it was done.  This may be different from the author; for
+  example, if the author wrote a patch and emailed it to another person who
+  used the patch to create the commit.
 - a **comment** describing this commit.
 
 Note that a commit does not itself contain any information about what
@@ -53,7 +53,7 @@ taken from the content currently stored in the index.
 
 ### The Object Model ###
 
-So, now that we've looked at the 3 main object types (the blob, tree and commit), 
+So, now that we've looked at the 3 main object types (blob, tree and commit), 
 let's take a quick look at how they all fit together.
 
 If we had a simple project with the following directory structure:
diff --git a/text/02_Git_Object_Db_Basics/3_Trust_and_Tags.markdown b/text/02_Git_Object_Db_Basics/3_Trust_and_Tags.markdown
@@ -3,9 +3,7 @@
 
 [fig:object-tag]
 
-A tag object contains an object, object type, tag name, the name of the
-person ("tagger") who created the tag, and a message, which may contain
-a signature, as can be seen using linkgit:git-cat-file[1]:
+A tag object contains an object name (called simply 'object'), object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain a signature, as can be seen using linkgit:git-cat-file[1]:
 
     $ git cat-file tag v1.5.0
     object 437b1b20df4b356c9342dac8d38849f24ef44f27
diff --git a/text/02a_Git_Directory_and_Working_Directory/0_ Git_Directory_and_Working_Directory.markdown b/text/02a_Git_Directory_and_Working_Directory/0_ Git_Directory_and_Working_Directory.markdown
@@ -2,14 +2,9 @@
 
 ### The Git Directory ###
 
-The 'git directory' is the directory that stores all the Git meta information
-about your project - including all of the objects (commits, trees, blobs, tags), 
-all of the pointers to where different branches are and more. 
+The 'git directory' is the directory that stores all Git's history and meta information for your project - including all of the objects (commits, trees, blobs, tags), all of the pointers to where different branches are and more. 
 
-There is only one Git Directory per project (as opposed to one per subdirectory like SVN or CVS), 
-and that directory is (by default, though not neccesarily) found in the '.git'
-directory in the root of your project.  If you look at the contents of that
-directory, you can see all of our important files:
+There is only one Git Directory per project (as opposed to one per subdirectory like with SVN or CVS), and that directory is (by default, though not necessarily) '.git' in the root of your project.  If you look at the contents of that directory, you can see all of your important files:
 
     $>tree -L 1
     .
@@ -29,6 +24,6 @@ directory, you can see all of our important files:
 The Git 'working directory' is the directory that holds the current checkout 
 of the files you are working on.  Files in this directory are often removed
 or replaced by Git as you switch branches - this is normal.  All your history 
-is stored in the Git Directory, the working directory is simply a temporary 
+is stored in the Git Directory; the working directory is simply a temporary 
 checkout place where you can modify the files until your next commit.
 
diff --git a/text/03_The_Git_Index/0_ The_Git_Index.markdown b/text/03_The_Git_Index/0_ The_Git_Index.markdown
@@ -2,14 +2,13 @@
 
 The Git index is used as a staging area between your working directory 
 and your repository.  You can use the index to build up a set of changes
-that you want to commit together relatively easily.  When you create a commit,
-what is committed is what is currently in the index, not what is in your working
+that you want to commit together.  When you create a commit, what is committed is what is currently in the index, not what is in your working
 directory.
 
 ### Looking at the Index ###
 
 The easiest way to see what is in the index is with the linkgit:git-status[1]
-command.  When you run the status, you can see what files are staged (currently in your index),
+command.  When you run git status, you can see which files are staged (currently in your index),
 which are modified but not yet staged, and which are completely untracked.
 
     $>git status
@@ -40,5 +39,5 @@ information as long as you have the name of the tree that it described.
 And with that, you should have a pretty good understanding of the basics of 
 what Git is doing behind the scenes, and why it is a bit different than most
 other SCM systems.  Don't worry if you don't totally understand it all right 
-now, we'll revisit all of these topics in the next sections. Now we're ready 
+now; we'll revisit all of these topics in the next sections. Now we're ready 
 to move on to installing, configuring and using Git.  
