Edit Tim Pope's commit guidelines for clarity

- Clarify that it's the end user that will get confused with rebasing when the body and summary of the commit message are mushed together.
- Edit the line that links to the original Tim Pope blog post, stating that we adapted it. We're no longer fully quoting him.

Fixes #696

Author: HonkingGoose

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

@@ -60,7 +60,7 @@ Getting in the habit of creating quality commit messages makes using and collabo
 As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.
 The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow.
 Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."
-Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]:
+Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope], and lightly adapted by us:
 
 [source,text]
 ----
@@ -70,7 +70,7 @@ 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
+the body entirely); tools like rebase will confuse you if you run the
 two together.
 
 Write your commit message in the imperative: "Fix bug" and not "Fixed bug"