Merge pull request #870 from rpjday/basics

Minor tweaks (rewording, punct, adding lists) to "Git Basics"

Author: ben

book/01-introduction/sections/basics.asc

@@ -2,21 +2,21 @@
 
 So, what is Git in a nutshell?
 This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you.
-As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool.
-Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar, and understanding those differences will help prevent you from becoming confused while using it.(((Subversion)))(((Perforce)))
+As you learn Git, try to clear your mind of the things you may know about other VCSs, such as CVS, Subversion or Perforce -- doing so will help you avoid subtle confusion when using the tool.
+Even though Git's user interface is fairly similar to these other VCSs, Git stores and thinks about information in a very different way, and understanding these differences will help you avoid becoming confused while using it.(((Subversion)))(((Perforce)))
 
 ==== Snapshots, Not Differences
 
 The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.
 Conceptually, most other systems store information as a list of file-based changes.
-These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.
+These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as _delta-based_ version control).
 
 .Storing data as changes to a base version of each file.
 image::images/deltas.png[Storing data as changes to a base version of each file.]
 
 Git doesn't think of or store its data this way.
-Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem.
-Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
+Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem.
+With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
 To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored.
 Git thinks about its data more like a *stream of snapshots*.
 
@@ -30,11 +30,11 @@ We'll explore some of the benefits you gain by thinking of your data this way wh
 
 ==== Nearly Every Operation Is Local
 
-Most operations in Git need only local files and resources to operate – generally no information is needed from another computer on your network.
+Most operations in Git need only local files and resources to operate -- generally no information is needed from another computer on your network.
 If you're used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers.
 Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
 
-For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you – it simply reads it directly from your local database.
+For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you -- it simply reads it directly from your local database.
 This means you see the project history almost instantly.
 If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
 
@@ -68,19 +68,19 @@ In fact, Git stores everything in its database not by file name but by the hash
 
 When you do actions in Git, nearly all of them only _add_ data to the Git database.
 It is hard to get the system to do anything that is not undoable or to make it erase data in any way.
-As in any VCS, you can lose or mess up changes you haven't committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
+As with any VCS, you can lose or mess up changes you haven't committed yet, but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
 
 This makes using Git a joy because we know we can experiment without the danger of severely screwing things up.
 For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_undoing>>.
 
 ==== The Three States
 
-Now, pay attention.
-This is the main thing to remember about Git if you want the rest of your learning process to go smoothly.
-Git has three main states that your files can reside in: committed, modified, and staged.
-Committed means that the data is safely stored in your local database.
-Modified means that you have changed the file but have not committed it to your database yet.
-Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
+Pay attention now -- here is the main thing to remember about Git if you want the rest of your learning process to go smoothly.
+Git has three main states that your files can reside in: _committed_, _modified_, and _staged_:
+
+* Committed means that the data is safely stored in your local database.
+* Modified means that you have changed the file but have not committed it to your database yet.
+* Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
 
 This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area.