Fix quote from Tim Pope's blog.

Author: HonkingGoose

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

@@ -66,23 +66,27 @@ Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[
 
 [source,text]
 ----
-Short (50 chars or less) summary of changes
+Capitalized, short (50 chars or less) summary
 
-More detailed explanatory text, if necessary.  Wrap it to
-about 72 characters or so.  In some contexts, the first
-line is treated as the subject of an email and the rest of
-the text as the body.  The blank line separating the
-summary from the body is critical (unless you omit the body
-entirely); tools like rebase can get confused if you run
-the two together.
+More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase can get confused if you run the
+two together.
+
+Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
+or "Fixes bug."  This convention matches up with commit messages generated
+by commands like git merge and git revert.
 
 Further paragraphs come after blank lines.
 
-  - Bullet points are okay, too
+- Bullet points are okay, too
+
+- Typically a hyphen or asterisk is used for the bullet, followed by a
+  single space, with blank lines in between, but conventions vary here
 
-  - Typically a hyphen or asterisk is used for the bullet,
-    preceded by a single space, with blank lines in
-    between, but conventions vary here
+- Use a hanging indent
 ----
 
 If all your commit messages follow this model, things will be much easier for you and the developers with whom you collaborate.