Merge pull request #915 from rpjday/objects

More minor tweaks to the "Git Objects" section

Author: ben

book/10-git-internals/sections/objects.asc

@@ -111,7 +111,7 @@ version 2
 
 But remembering the SHA-1 key for each version of your file isn't practical; plus, you aren't storing the filename in your system -- just the content.
 This object type is called a _blob_.
-You can have Git tell you the object type of any object in Git, given its SHA-1 key, with `cat-file -t`:
+You can have Git tell you the object type of any object in Git, given its SHA-1 key, with `git cat-file -t`:
 
 [source,console]
 ----
@@ -122,7 +122,7 @@ blob
 [[_tree_objects]]
 ==== Tree Objects
 
-The next type we'll look at is the _tree_, which solves the problem of storing the filename and also allows you to store a group of files together.
+The next type of Git object we'll examine is the _tree_, which solves the problem of storing the filename and also allows you to store a group of files together.
 Git stores content in a manner similar to a UNIX filesystem, but a bit simplified.
 All the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents.
 A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename.
@@ -145,15 +145,15 @@ $ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
 ----
 
-Conceptually, the data that Git is storing is something like this:
+Conceptually, the data that Git is storing looks something like this:
 
 .Simple version of the Git data model.
 image::images/data-model-1.png[Simple version of the Git data model.]
 
 You can fairly easily create your own tree.
 Git normally creates a tree by taking the state of your staging area or index and writing a series of tree objects from it.
 So, to create a tree object, you first have to set up an index by staging some files.
-To create an index with a single entry – the first version of your `test.txt` file – you can use the plumbing command `update-index`.
+To create an index with a single entry -- the first version of your `test.txt` file -- you can use the plumbing command `git update-index`.
 You use this command to artificially add the earlier version of the `test.txt` file to a new staging area.
 You must pass it the `--add` option because the file doesn't yet exist in your staging area (you don't even have a staging area set up yet) and `--cacheinfo` because the file you're adding isn't in your directory but is in your database.
 Then, you specify the mode, SHA-1, and filename:
@@ -166,10 +166,10 @@ $ git update-index --add --cacheinfo 100644 \
 
 In this case, you're specifying a mode of `100644`, which means it's a normal file.
 Other options are `100755`, which means it's an executable file; and `120000`, which specifies a symbolic link.
-The mode is taken from normal UNIX modes but is much less flexible – these three modes are the only ones that are valid for files (blobs) in Git (although other modes are used for directories and submodules).
+The mode is taken from normal UNIX modes but is much less flexible -- these three modes are the only ones that are valid for files (blobs) in Git (although other modes are used for directories and submodules).
 
-Now, you can use the `write-tree` command to write the staging area out to a tree object.
-No `-w` option is needed – calling `write-tree` automatically creates a tree object from the state of the index if that tree doesn't yet exist:
+Now, you can use `git write-tree` to write the staging area out to a tree object.
+No `-w` option is needed -- calling this command automatically creates a tree object from the state of the index if that tree doesn't yet exist:
 
 [source,console]
 ----
@@ -179,7 +179,7 @@ $ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 100644 blob 83baae61804e65cc73a7201a7252750c76066a30      test.txt
 ----
 
-You can also verify that this is a tree object:
+You can also verify that this is a tree object using the same `git cat-file` command you saw earlier:
 
 [source,console]
 ----
@@ -211,8 +211,8 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
 
 Notice that this tree has both file entries and also that the `test.txt` SHA-1 is the ``version 2'' SHA-1 from earlier (`1f7a7a`).
 Just for fun, you'll add the first tree as a subdirectory into this one.
-You can read trees into your staging area by calling `read-tree`.
-In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option to `read-tree`:
+You can read trees into your staging area by calling `git read-tree`.
+In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option with this command:
 
 [source,console]
 ----
@@ -234,7 +234,7 @@ image::images/data-model-2.png[The content structure of your current Git data.]
 [[_git_commit_objects]]
 ==== Commit Objects
 
-You have three trees that specify the different snapshots of your project that you want to track, but the earlier problem remains: you must remember all three SHA-1 values in order to recall the snapshots.
+If you've done all of the above, you now have three trees that represent the different snapshots of your project that you want to track, but the earlier problem remains: you must remember all three SHA-1 values in order to recall the snapshots.
 You also don't have any information about who saved the snapshots, when they were saved, or why they were saved.
 This is the basic information that the commit object stores for you.
 
@@ -249,7 +249,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d
 
 You will get a different hash value because of different creation time and author data.
 Replace commit and tag hashes with your own checksums further in this chapter.
-Now you can look at your new commit object with `cat-file`:
+Now you can look at your new commit object with `git cat-file`:
 
 [source,console]
 ----
@@ -310,8 +310,8 @@ Date:   Fri May 22 18:09:34 2009 -0700
 
 Amazing.
 You've just done the low-level operations to build up a Git history without using any of the front end commands.
-This is essentially what Git does when you run the `git add` and `git commit` commands – it stores blobs for the files that have changed, updates the index, writes out trees, and writes commit objects that reference the top-level trees and the commits that came immediately before them.
-These three main Git objects – the blob, the tree, and the commit – are initially stored as separate files in your `.git/objects` directory.
+This is essentially what Git does when you run the `git add` and `git commit` commands -- it stores blobs for the files that have changed, updates the index, writes out trees, and writes commit objects that reference the top-level trees and the commits that came immediately before them.
+These three main Git objects -- the blob, the tree, and the commit -- are initially stored as separate files in your `.git/objects` directory.
 Here are all the objects in the example directory now, commented with what they store:
 
 [source,console]
@@ -336,9 +336,9 @@ image::images/data-model-3.png[All the reachable objects in your Git directory.]
 
 ==== Object Storage
 
-We mentioned earlier that a header is stored with the content.
-Let's take a minute to look at how Git stores its objects.
-You'll see how to store a blob object – in this case, the string ``what is up, doc?'' – interactively in the Ruby scripting language.
+We mentioned earlier that there is a header stored with every object you commit to your Git object database.
+Let's take a minute to see how Git stores its objects.
+You'll see how to store a blob object -- in this case, the string ``what is up, doc?'' -- interactively in the Ruby scripting language.
 
 You can start up interactive Ruby mode with the `irb` command:
 
@@ -349,8 +349,8 @@ $ irb
 => "what is up, doc?"
 ----
 
-Git constructs a header that starts with the type of the object, in this case a blob.
-Then, it adds a space followed by the size of the content and finally a null byte:
+Git first constructs a header which starts by identifying the type of object -- in this case, a blob.
+To that first part of the header, Git adds a space followed by the size in bytes  of the content, and adding a final null byte:
 
 [source,console]
 ----