inspection and comparison

progit · ben · Oct 21, 2014 · Oct 8, 2014 · Oct 9, 2014 · Oct 9, 2014
commit 0cce6a40cbb1987869e0a26ee5b9eea435477312
diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc
@@ -49,6 +49,7 @@ Annotated tags, however, are stored as full objects in the Git database.
 They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
 It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too.
 
+[[_annotated_tags]]
 ==== Annotated Tags
 
 (((tags, annotated)))

diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc
@@ -466,6 +466,7 @@ $ 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.
 
+[[_build_number]]
 ==== Generating a Build Number
 
 (((build numbers)))(((git commands, describe)))
@@ -486,6 +487,7 @@ The `git describe` command favors annotated tags (tags created with the `-a` or
 You can also use this string as the target of a checkout or show command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever.
 For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated.
 
+[[_preparing_release]]
 ==== Preparing a Release
 
 (((releasing)))(((git commands, archive)))
@@ -510,6 +512,7 @@ $ git archive master --prefix='project/' --format=zip > `git describe master`.zi
 
 You now have a nice tarball and a zip archive of your project release that you can upload to your website or e-mail to people.
 
+[[_the_shortlog]]
 ==== The Shortlog
 
 (((git commands, shortlog)))

diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc
@@ -1,3 +1,4 @@
+[[_revision_selection]]
 === Revision Selection
 
 Git allows you to specify specific commits or a range of commits in several ways.

diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc
@@ -298,10 +298,25 @@ This command is only mentioned and entirely covered in <<_git_submodules>>.
 
 ==== show
 
+The `git show` command can show a Git object in a simple and human readable way. Normally you would use this to show the information about a tag or a commit.
+
+We first use it to show annotated tag information in <<_annotated_tags>>.
+
+Later we use it quite a bit in <<_revision_selection>> to show the commits that our various revision selections resolve to.
+
+One of the more interesting things we do with `git show` is in <<_manual_remerge>> to extract specific file contents of various stages during a merge conflict.
+
 ==== shortlog
 
+The `git shortlog` command is used to summarize the output of `git log`. It will take many of the same options that the `git log` command will but instead of listing out all of the commits it will present a summary of the commits grouped by author.
+
+We showed how to use it to create a nice changelog in <<_the_shortlog>>.
+
 ==== describe
 
+The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA but more understandable.
+
+We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a string to name our release file after.
 
 === Patching