Merge pull request #845 from rpjday/ch1_grammar

Minor grammar/font/NOTE/clarification tweaks to Chapter 1.

Author: ben

book/01-introduction/sections/basics.asc

@@ -30,7 +30,7 @@ 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 only need 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.
 
@@ -39,7 +39,7 @@ 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.
 
 This also means that there is very little you can't do if you're offline or off VPN.
-If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload.
+If you get on an airplane or a train and want to do a little work, you can commit happily (to your _local_ copy, remember?) until you get to a network connection to upload.
 If you go home and can't get your VPN client working properly, you can still work.
 In many other systems, doing so is either impossible or painful.
 In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline).
@@ -66,7 +66,7 @@ In fact, Git stores everything in its database not by file name but by the hash
 
 ==== Git Generally Only Adds Data
 
-When you do actions in Git, nearly all of them only add data to the Git database.
+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.
 
@@ -88,18 +88,18 @@ This leads us to the three main sections of a Git project: the Git directory, th
 image::images/areas.png["Working tree, staging area, and Git directory."]
 
 The Git directory is where Git stores the metadata and object database for your project.
-This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
+This is the most important part of Git, and it is what is copied when you _clone_ a repository from another computer.
 
 The working tree is a single checkout of one version of the project.
 These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
 
 The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit.
-It's sometimes referred to as the ``index'', but it's also common to refer to it as the staging area.
+Its technical name in Git parlance is the ``index'', but the phrase ``staging area'' works just as well.
 
 The basic Git workflow goes something like this:
 
 1. You modify files in your working tree.
-2. You stage the files, adding snapshots of them to your staging area.
+2. You selectively stage just those changes you want to be part of your next commit, which adds _only_ those changes to the staging area.
 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
 
 If a particular version of a file is in the Git directory, it's considered committed.

book/01-introduction/sections/command-line.asc

@@ -1,10 +1,10 @@
 === The Command Line
 
 There are a lot of different ways to use Git.
-There are the original command line tools, and there are many graphical user interfaces of varying capabilities.
+There are the original command-line tools, and there are many graphical user interfaces of varying capabilities.
 For this book, we will be using Git on the command line.
-For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity.
-If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true.
+For one, the command line is the only place you can run _all_ Git commands – most of the GUIs implement only a partial subset of Git functionality for simplicity.
+If you know how to run the command-line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true.
 Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
 
 So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.

book/01-introduction/sections/first-time-setup.asc

@@ -8,9 +8,9 @@ You can also change them at any time by running through the commands again.
 Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.(((git commands, config)))
 These variables can be stored in three different places:
 
-1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories.
+1. `/etc/gitconfig` file: Contains values applied to every user on the system and all their repositories.
   If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
-2. `~/.gitconfig` or `~/.config/git/config` file: Specific to your user.
+2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user.
   You can make Git read and write to this file specifically by passing the `--global` option.
 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository.
 
@@ -82,7 +82,7 @@ An example on a Windows system may include a prematurely terminated Git operatio
 
 ==== Checking Your Settings
 
-If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
+If you want to check your configuration settings, you can use the `git config --list` command to list all the settings Git can find at that point:
 
 [source,console]
 ----
@@ -106,3 +106,15 @@ You can also check what Git thinks a specific key's value is by typing `git conf
 $ git config user.name
 John Doe
 ----
+
+[NOTE]
+====
+Since Git might read the same configuration variable value from more than one file, it's possible that you have an unexpected value for one of these values and you don't know why.
+In cases like that, you can query Git as to the _origin_ for that value, and it will tell you which configuration file had the final say in setting that value:
+
+[source,console]
+----
+$ git config --show-origin rerere.autoUpdate
+file:/home/johndoe/.gitconfig	false
+----
+====

book/01-introduction/sections/help.asc

@@ -10,7 +10,7 @@ $ git <verb> --help
 $ man git-<verb>
 ----
 
-For example, you can get the manpage help for the config command by running(((git commands, help)))
+For example, you can get the manpage help for the `git config` command by running(((git commands, help)))
 
 [source,console]
 ----

book/01-introduction/sections/history.asc

@@ -17,4 +17,4 @@ Some of the goals of the new system were as follows:
 *  Able to handle large projects like the Linux kernel efficiently (speed and data size)
 
 Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities.
-It's incredibly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<_git_branching>>).
+It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<_git_branching>>).

book/01-introduction/sections/installing.asc

@@ -15,7 +15,7 @@ Since Git is quite excellent at preserving backwards compatibility, any version
 
 (((Linux, installing)))
 If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution.
-If you're on Fedora for example, you can use `dnf`:
+If you're on Fedora for example (or any closely-related RPM-based distro such as RHEL or CentOS), you can use `dnf`:
 
 [source,console]
 ----