Up through colors

book/02-git-basics/1-git-basics.asc

@@ -252,6 +252,7 @@ M  lib/simplegit.rb
 
 New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified.  So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged.
 
+[[_ignoring]]
 ==== Ignoring Files
 
 Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked.

book/07-git-tools/1-git-tools.asc

@@ -705,7 +705,7 @@ This is a nice shortcut to recover stashed work easily and work on it in a new b
 
 ==== Cleaning your Working Directory
 
-
+[[_signing]]
 === Signing Your Work
 
 Git is cryptographically secure, but it's not foolproof. If you're taking work from others on the internet and want to verify that commits are actually from a trusted source, Git has a few ways to sign and verify work using GPG.

book/08-customizing-git/1-customizing-git.asc

@@ -1,152 +1,213 @@
 == Customizing Git
 
-So far, I've covered the basics of how Git works and how to use it, and I've introduced a number of tools that Git provides to help you use it easily and efficiently.
-In this chapter, I'll go through some operations that you can use to make Git operate in a more customized fashion by introducing several important configuration settings and the hooks system.
+So far, we've covered the basics of how Git works and how to use it, and we've introduced a number of tools that Git provides to help you use it easily and efficiently.
+In this chapter, we'll see how you can make Git operate in a more customized fashion, by introducing several important configuration settings and the hooks system.
 With these tools, it's easy to get Git to work exactly the way you, your company, or your group needs it to.
 
 === Git Configuration
 
-As you briefly saw in the <<_getting_started>>, you can specify Git configuration settings with the `git config` command.
+As you briefly saw in <<_getting_started>>, you can specify Git configuration settings with the `git config` command.
 One of the first things you did was set up your name and e-mail address:
 
-  $ git config --global user.name "John Doe"
-  $ git config --global user.email [email protected]
+[source,shell]
+----
+$ git config --global user.name "John Doe"
+$ git config --global user.email [email protected]
+----
 
 Now you'll learn a few of the more interesting options that you can set in this manner to customize your Git usage.
 
-You saw some simple Git configuration details in the <<_getting_started>>, but I'll go over them again quickly here.
-Git uses a series of configuration files to determine non-default behavior that you may want.
+First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want.
 The first place Git looks for these values is in an `/etc/gitconfig` file, which contains values for every user on the system and all of their repositories.
 If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
 
-The next place Git looks is the `~/.gitconfig` file, which is specific to each user.
+The next place Git looks is the `~/.gitconfig` (or `~/.config/git/config`) file, which is specific to each user.
 You can make Git read and write to this file by passing the `--global` option.
 
-Finally, Git looks for configuration values in the config file in the Git directory (`.git/config`) of whatever repository you're currently using.
+Finally, Git looks for configuration values in the configuration file in the Git directory (`.git/config`) of whatever repository you're currently using.
 These values are specific to that single repository.
-Each level overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance.
-You can also set these values by manually editing the file and inserting the correct syntax, but it's generally easier to run the `git config` command.
+
+Each of these ``levels'' (system, global, local) overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance.
+
+[NOTE]
+====
+Git's configuration files are plain-text, so you can also set these values by manually editing the file and inserting the correct syntax.
+It's generally easier to run the `git config` command, though.
+====
 
 ==== Basic Client Configuration
 
-The configuration options recognized by Git fall into two categories: client side and server side.
-The majority of the options are client side–configuring your personal working preferences.
-Although tons of options are available, I'll only cover the few that either are commonly used or can significantly affect your workflow.
-Many options are useful only in edge cases that I won't go over here.
+The configuration options recognized by Git fall into two categories: client-side and server-side.
+The majority of the options are client-side – configuring your personal working preferences.
+Many, _many_ configuration options are supported, but a large fraction of them are only useful in certain edge cases.
+We'll only be covering the most common and most useful here.
 If you want to see a list of all the options your version of Git recognizes, you can run
 
-  $ git config --help
+[source,shell]
+----
+$ man git-config
+----
 
-The manual page for `git config` lists all the available options in quite a bit of detail.
+This command lists all the available options in quite a bit of detail.
+You can also find this reference material at http://git-scm.com/docs/git-config.html[].
 
-===== core.editor
+===== `core.editor`
 
-By default, Git uses whatever you've set as your default text editor or else falls back to the Vi editor to create and edit your commit and tag messages.
+By default, Git uses whatever you've set as your default text editor (`$VISUAL` or `$EDITOR`) or else falls back to the `vi` editor to create and edit your commit and tag messages.
 To change that default to something else, you can use the `core.editor` setting:
 
-  $ git config --global core.editor emacs
+[source,shell]
+----
+$ git config --global core.editor emacs
+----
 
-Now, no matter what is set as your default shell editor variable, Git will fire up Emacs to edit messages.
+Now, no matter what is set as your default shell editor, Git will fire up Emacs to edit messages.
 
-===== commit.template
+===== `commit.template`
 
 If you set this to the path of a file on your system, Git will use that file as the default message when you commit.
-For instance, suppose you create a template file at `$HOME/.gitmessage.txt` that looks like this:
+For instance, suppose you create a template file at `~/.gitmessage.txt` that looks like this:
 
-  subject line
+[source]
+----
+subject line
 
-  what happened
+what happened
 
-  [ticket: X]
+[ticket: X]
+----
 
 To tell Git to use it as the default message that appears in your editor when you run `git commit`, set the `commit.template` configuration value:
 
-  $ git config --global commit.template $HOME/.gitmessage.txt
-  $ git commit
+[source,shell]
+----
+$ git config --global commit.template ~/.gitmessage.txt
+$ git commit
+----
 
 Then, your editor will open to something like this for your placeholder commit message when you commit:
 
-  subject line
-
-  what happened
-
-  [ticket: X]
-  # Please enter the commit message for your changes. Lines starting
-  # with '#' will be ignored, and an empty message aborts the commit.
-  # On branch master
-  # Changes to be committed:
-  #   (use "git reset HEAD <file>..." to unstage)
-  #
-  # modified:   lib/test.rb
-  #
-  ~
-  ~
-  ".git/COMMIT_EDITMSG" 14L, 297C
+[source]
+----
+subject line
+
+what happened
+
+[ticket: X]
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   lib/test.rb
+#
+~
+~
+".git/COMMIT_EDITMSG" 14L, 297C
+----
 
-If you have a commit-message policy in place, then putting a template for that policy on your system and configuring Git to use it by default can help increase the chance of that policy being followed regularly.
+If your team has a commit-message policy, then putting a template for that policy on your system and configuring Git to use it by default can help increase the chance of that policy being followed regularly.
 
-===== core.pager
+===== `core.pager`
 
-The core.pager setting determines what pager is used when Git pages output such as `log` and `diff`.
+This setting determines which pager is used when Git pages output such as `log` and `diff`.
 You can set it to `more` or to your favorite pager (by default, it's `less`), or you can turn it off by setting it to a blank string:
 
-  $ git config --global core.pager ''
+[source,shell]
+----
+$ git config --global core.pager ''
+----
 
 If you run that, Git will page the entire output of all commands, no matter how long they are.
 
-===== user.signingkey
+===== `user.signingkey`
 
-If you're making signed annotated tags (as discussed in <<_git_basics_chapter>>), setting your GPG signing key as a configuration setting makes things easier.
+If you're making signed annotated tags (as discussed in <<_signing>>), setting your GPG signing key as a configuration setting makes things easier.
 Set your key ID like so:
 
-  $ git config --global user.signingkey <gpg-key-id>
+[source,shell]
+----
+$ git config --global user.signingkey <gpg-key-id>
+----
 
 Now, you can sign tags without having to specify your key every time with the `git tag` command:
 
-  $ git tag -s <tag-name>
+[source,shell]
+----
+$ git tag -s <tag-name>
+----
+
+===== `core.excludesfile`
+
+You can put patterns in your project's `.gitignore` file to have Git not see them as untracked files or try to stage them when you run `git add` on them, as discussed in <<_ignoring>>.
+
+But sometimes you want to ignore certain files for all repositories that you work with.
+If your computer is running Mac OS X, you're probably familiar with `.DS_Store` files.
+If your preferred editor is Emacs or Vim, you know about files that end with a `~`.
+
+This setting lets you write a kind of global `.gitignore` file.
+If you create a `~/.gitignore_global` file with these contents:
+
+[source]
+----
+*~
+.DS_Store
+----
+
+…and you run `git config --global core.excludesfile ~/.gitignore_global`, Git will never again bother you about those files.
 
-===== core.excludesfile
+===== `help.autocorrect`
 
-You can put patterns in your project's `.gitignore` file to have Git not see them as untracked files or try to stage them when you run `git add` on them, as discussed in <<_git_basics_chapter>>.
-However, if you want another file outside of your project to hold those values or have extra values, you can tell Git where that file is with the `core.excludesfile` setting.
-Simply set it to the path of a file that has content similar to what a `.gitignore` file would have.
+If you mistype a command, it shows you something like this:
 
-===== help.autocorrect
+[source,shell]
+----
+$ git chekcout master
+git: 'chekcout' is not a git command. See 'git --help'.
 
-This option is available only in Git 1.6.1 and later.
-If you mistype a command in Git 1.6, it shows you something like this:
+Did you mean this?
+	checkout
+----
 
-  $ git com
-  git: 'com' is not a git-command. See 'git --help'.
+Git helpfully tries to figure out what you meant, but it still refuses to do it.
+If you set `help.autocorrect` to 1, Git will actually run this command for you:
 
-  Did you mean this?
-       commit
+[source,shell]
+----
+$ git chekcout master
+WARNING: You called a Git command named 'chekcout', which does not exist.
+Continuing under the assumption that you meant 'checkout'
+in 0.1 seconds automatically...
+----
 
-If you set `help.autocorrect` to 1, Git will automatically run the command if it has only one match under this scenario.
+Note that ``0.1 seconds'' business. `help.autocorrect` is actually an integer which represents tenths of a second.
+So if you set it to 50, Git will give you 5 seconds to change your mind before executing the autocorrected command.
 
 ==== Colors in Git
 
-Git can color its output to your terminal, which can help you visually parse the output quickly and easily.
+Git fully supports colored terminal output, which greatly aids in visually parsing command output quickly and easily.
 A number of options can help you set the coloring to your preference.
 
-===== color.ui
+===== `color.ui`
 
-Git automatically colors most of its output if you ask it to.
-You can get very specific about what you want colored and how; but to turn on all the default terminal coloring, set `color.ui` to true:
+Git automatically colors most of its output, but there's a master switch if you don't like this behavior.
+To turn off all Git's colored terminal output, do this:
 
-  $ git config --global color.ui true
+[source,shell]
+----
+$ git config --global color.ui false
+----
 
-When that value is set, Git colors its output if the output goes to a terminal.
-Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you're redirecting Git commands to a file or piping them to another command.
-This setting was added in Git version 1.5.5; if you have an older version, you'll have to specify all the color settings individually.
+The default setting is `auto`, which colors output when it's going straight to a terminal, but omits the color-control codes when the output is redirected to a pipe or a file.
 
-You'll rarely want `color.ui = always`.
-In most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes.
-The `color.ui = true` setting is almost always what you'll want to use.
+You can also set it to `always` to ignore the difference between terminals and pipes.
+You'll rarely want this; in most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes.
+The default setting is almost always what you'll want.
 
 ===== `color.*`
 
-If you want to be more specific about which commands are colored and how, or you have an older version, Git provides verb-specific coloring settings.
+If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings.
 Each of these can be set to `true`, `false`, or `always`:
 
   color.branch
@@ -159,10 +220,8 @@ For example, to set the meta information in your diff output to blue foreground,
 
   $ git config --global color.diff.meta "blue black bold"
 
-You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white.
-If you want an attribute like bold in the previous example, you can choose from bold, dim, ul, blink, and reverse.
-
-See the `git config` manpage for all the subsettings you can configure, if you want to do that.
+You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
+If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul` (underline), `blink`, and `reverse` (swap foreground and background).
 
 ==== External Merge and Diff Tools