chapter 5: minor rewording for clarity

Also change output of "git shortlog" so that number of
log entries matched what is actually printed.

Signed-off-by: Robert P. J. Day <[email protected]>

Author: robertpjday

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

@@ -1,7 +1,7 @@
 === Maintaining a Project
 
 (((maintaining a project)))
-In addition to knowing how to effectively contribute to a project, you'll likely need to know how to maintain one.
+In addition to knowing how to contribute effectively to a project, you'll likely need to know how to maintain one.
 This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project.
 Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run.
 
@@ -485,7 +485,7 @@ Also, if you include instructions in the tag message, running `git show <tag>` w
 
 (((build numbers)))(((git commands, describe)))
 Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit.
-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:
+In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git):
 
 [source,console]
 ----
@@ -495,10 +495,10 @@ 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.
-If you're describing a commit that you have directly tagged, it gives you the tag name.
+If you're describing a commit that you have directly tagged, it gives you simply the tag name.
 
 The `git describe` command favors annotated tags (tags created with the `-a` or `-s` flag), so release tags should be created this way if you're using `git describe`, to ensure the commit is named properly when described.
-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.
+You can also use this string as the target of a `git checkout` or `git 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]]
@@ -537,7 +537,7 @@ It summarizes all the commits in the range you give it; for example, the followi
 [source,console]
 ----
 $ git shortlog --no-merges master --not v1.0.1
-Chris Wanstrath (8):
+Chris Wanstrath (6):
       Add support for annotated tags to Grit::Tag
       Add packed-refs annotated tag support.
       Add Grit::Commit#to_patch