Fix console coloring in maintaining.asc

Author: crd

book/05-distributed-git/sections/maintaining.asc

@@ -15,16 +15,16 @@ The maintainer of the Git project tends to namespace these branches as well –
 As you'll remember, you can create the branch based off your master branch like this:
 
 [source,console]
------
+----
 $ git branch sc/ruby_client master
------
+----
 
 Or, if you want to also switch to it immediately, you can use the `checkout -b` option:
 
 [source,console]
------
+----
 $ git checkout -b sc/ruby_client master
------
+----
 
 Now you're ready to add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches.
 
@@ -42,9 +42,9 @@ If you received the patch from someone who generated it with the `git diff` or a
 Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this:
 
 [source,console]
------
+----
 $ git apply /tmp/patch-ruby-client.patch
------
+----
 
 This modifies the files in your working directory.
 It's almost identical to running a `patch -p1` command to apply the patch, although it's more paranoid and accepts fewer fuzzy matches than patch.
@@ -56,11 +56,11 @@ It won't create a commit for you – after running it, you must stage and commit
 You can also use git apply to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch:
 
 [source,console]
------
+----
 $ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 error: patch failed: ticgit.gemspec:1
 error: ticgit.gemspec: patch does not apply
------
+----
 
 If there is no output, then the patch should apply cleanly.
 This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want.
@@ -78,14 +78,14 @@ Technically, `git am` is built to read an mbox file, which is a simple, plain-te
 It looks something like this:
 
 [source,console]
------
+----
 From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 From: Jessica Smith <[email protected]>
 Date: Sun, 6 Apr 2008 10:17:23 -0700
 Subject: [PATCH 1/2] add limit to log function
 
 Limit log functionality to the first 20
------
+----
 
 This is the beginning of the output of the format-patch command that you saw in the previous section.
 This is also a valid mbox email format.
@@ -95,16 +95,17 @@ If you run a mail client that can save several emails out in mbox format, you ca
 However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it:
 
 [source,console]
------
+----
 $ git am 0001-limit-log-function.patch
 Applying: add limit to log function
------
+----
 
 You can see that it applied cleanly and automatically created the new commit for you.
 The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email.
 For example, if this patch was applied from the mbox example above, the commit generated would look something like this:
 
------
+[source,console]
+----
 $ git log --pretty=fuller -1
 commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 Author:     Jessica Smith <[email protected]>
@@ -115,7 +116,7 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700
    add limit to log function
 
    Limit log functionality to the first 20
------
+----
 
 The `Commit` information indicates the person who applied the patch and the time it was applied.
 The `Author` information is the individual who originally created the patch and when it was originally created.
@@ -125,7 +126,7 @@ Perhaps your main branch has diverged too far from the branch the patch was buil
 In that case, the `git am` process will fail and ask you what you want to do:
 
 [source,console]
------
+----
 $ git am 0001-seeing-if-this-helps-the-gem.patch
 Applying: seeing if this helps the gem
 error: patch failed: ticgit.gemspec:1
@@ -134,48 +135,48 @@ Patch failed at 0001.
 When you have resolved this problem run "git am --resolved".
 If you would prefer to skip this patch, instead run "git am --skip".
 To restore the original branch and stop patching run "git am --abort".
------
+----
 
 This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation.
 You solve this issue much the same way – edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch:
 
 [source,console]
------
+----
 $ (fix the file)
 $ git add ticgit.gemspec
 $ git am --resolved
 Applying: seeing if this helps the gem
------
+----
 
 If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge.
 This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository.
 If you do have that commit – if the patch was based on a public commit – then the `-3` option is generally much smarter about applying a conflicting patch:
 
 [source,console]
------
+----
 $ git am -3 0001-seeing-if-this-helps-the-gem.patch
 Applying: seeing if this helps the gem
 error: patch failed: ticgit.gemspec:1
 error: ticgit.gemspec: patch does not apply
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 No changes -- Patch already applied.
------
+----
 
 In this case, this patch had already been applied.
 Without the `-3` option, it looks like a conflict.
 
 If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it:
 
 [source,console]
------
+----
 $ git am -3 -i mbox
 Commit Body is:
 --------------------------
 seeing if this helps the gem
 --------------------------
 Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
------
+----
 
 This is nice if you have a number of patches saved, because you can view the patch first if you don't remember what it is, or not apply the patch if you've already done so.
 
@@ -190,11 +191,11 @@ If your contribution came from a Git user who set up their own repository, pushe
 For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally:
 
 [source,console]
------
+----
 $ git remote add jessica git://github.com/jessica/myproject.git
 $ git fetch jessica
 $ git checkout -b rubyclient jessica/ruby-client
------
+----
 
 If she emails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup.
 
@@ -210,12 +211,12 @@ If you aren't working with a person consistently but still want to pull from the
 This does a one-time pull and doesn't save the URL as a remote reference:
 
 [source,console]
------
+----
 $ git pull https://github.com/onetimeguy/project
 From https://github.com/onetimeguy/project
  * branch            HEAD       -> FETCH_HEAD
 Merge made by recursive.
------
+----
 
 [[_what_is_introduced]]
 ==== Determining What Is Introduced
@@ -231,7 +232,7 @@ This does the same thing as the `master..contrib` format that we used earlier.
 For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this:
 
 [source,console]
------
+----
 $ git log contrib --not master
 commit 5b6235bd297351589efc4d73316f0a68d484f118
 Author: Scott Chacon <[email protected]>
@@ -244,17 +245,17 @@ Author: Scott Chacon <[email protected]>
 Date:   Mon Oct 22 19:38:36 2008 -0700
 
     updated the gemspec to hopefully work better
------
+----
 
 To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit.
 
 To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results.
 You may think to run this:
 
 [source,console]
------
+----
 $ git diff master
------
+----
 
 This command gives you a diff, but it may be misleading.
 If your `master` branch has moved forward since you created the topic branch from it, then you'll get seemingly strange results.
@@ -269,19 +270,19 @@ You do that by having Git compare the last commit on your topic branch with the
 Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it:
 
 [source,console]
------
+----
 $ git merge-base contrib master
 36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
 $ git diff 36c7db
------
+----
 
 However, that isn't convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax.
 In the context of the `diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch:
 
 [source,console]
------
+----
 $ git diff master...contrib
------
+----
 
 This command shows you only the work your current topic branch has introduced since its common ancestor with master.
 That is a very useful syntax to remember.
@@ -376,12 +377,12 @@ image::images/rebasing-1.png[Example history before a cherry-pick.]
 If you want to pull commit `e43a6` into your master branch, you can run
 
 [source,console]
------
+----
 $ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
 Finished one cherry-pick.
 [master]: created a0a41a9: "More friendly message when locking the index fails."
  3 files changed, 17 insertions(+), 3 deletions(-)
------
+----
 
 This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different.
 Now your history looks like this:
@@ -423,49 +424,49 @@ You can create a new tag as discussed in <<_git_basics_chapter>>.
 If you decide to sign the tag as the maintainer, the tagging may look something like this:
 
 [source,console]
------
+----
 $ git tag -s v1.5 -m 'my signed 1.5 tag'
 You need a passphrase to unlock the secret key for
 user: "Scott Chacon <[email protected]>"
 1024-bit DSA key, ID F721C45A, created 2009-02-09
------
+----
 
 If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags.
 The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content.
 To do this, you can figure out which key you want by running `gpg --list-keys`:
 
 [source,console]
------
+----
 $ gpg --list-keys
 /Users/schacon/.gnupg/pubring.gpg
 ---------------------------------
 pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
 uid                  Scott Chacon <[email protected]>
 sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
------
+----
 
 Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob:
 
 [source,console]
------
+----
 $ gpg -a --export F721C45A | git hash-object -w --stdin
 659ef797d181633c87ec71ac3f9ba29fe5775b92
------
+----
 
 Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you:
 
 [source,console]
------
+----
 $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
------
+----
 
 If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone.
 If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG:
 
 [source,console]
------
+----
 $ git show maintainer-pgp-pub | gpg --import
------
+----
 
 They can use that key to verify all your signed tags.
 Also, if you include instructions in the tag message, running `git show <tag>` will let you give the end user more specific instructions about tag verification.
@@ -478,10 +479,10 @@ Because Git doesn't have monotonically increasing numbers like 'v123' or the equ
 Git gives you the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you're describing:
 
 [source,console]
------
+----
 $ git describe master
 v1.6.2-rc1-20-g8c5b85c
------
+----
 
 This way, you can export a snapshot or build and name it something understandable to people.
 In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this.
@@ -500,19 +501,19 @@ One of the things you'll want to do is create an archive of the latest snapshot
 The command to do this is `git archive`:
 
 [source,console]
------
+----
 $ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
 $ ls *.tar.gz
 v1.6.2-rc1-20-g8c5b85c.tar.gz
------
+----
 
 If someone opens that tarball, they get the latest snapshot of your project under a project directory.
 You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`:
 
 [source,console]
------
+----
 $ git archive master --prefix='project/' --format=zip > `git describe master`.zip
------
+----
 
 You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people.
 
@@ -525,7 +526,7 @@ A nice way of quickly getting a sort of changelog of what has been added to your
 It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1:
 
 [source,console]
------
+----
 $ git shortlog --no-merges master --not v1.0.1
 Chris Wanstrath (8):
       Add support for annotated tags to Grit::Tag
@@ -540,6 +541,6 @@ Tom Preston-Werner (4):
       dynamic version method
       Version bump to 1.0.2
       Regenerated gemspec for version 1.0.2
------
+----
 
 You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list.