docs: tweak wording, punctuation for better readability stable
authorGreg Ward <greg@gerg.ca>
Mon, 13 Apr 2015 15:42:42 -0400
branchstable
changeset 1267 8cc6e90354a9
parent 1266 c94aaf6df69c
child 1268 ba3ff8c00304
docs: tweak wording, punctuation for better readability
docs/user-guide.rst
--- a/docs/user-guide.rst	Mon Apr 13 15:00:05 2015 -0400
+++ b/docs/user-guide.rst	Mon Apr 13 15:42:42 2015 -0400
@@ -205,7 +205,7 @@
 Changeset obsolescence under the hood
 -------------------------------------
 
-So far, everything has gone just fine. We haven't run into merge
+So far, everything has gone just fine: we haven't run into merge
 conflicts or other trouble. Before we start exploring advanced usage
 that can run into trouble, let's step back and see what happens when
 Mercurial marks changesets obsolete. That will make it much easier to
@@ -217,8 +217,8 @@
 *successors*. The obsolete changesets are the *precursors* of their
 successors. This applies equally to built-in commands (``commit
 --amend``), commands added by ``evolve`` (``amend``, ``prune``,
-``uncommit``, ``fold``), and even commands provided by other
-extensions (``rebase``, ``histedit``).
+``uncommit``, ``fold``), and commands provided by other extensions
+(``rebase``, ``histedit``).
 
 Another way of looking at it is that obsolescence is second-order
 version control, i.e. the history of your history. We'll cover this in
@@ -353,7 +353,7 @@
 ===================================
 
 Sometimes you don't notice your mistakes until after you have
-committed some new changesets on top of them. ::
+committed new changesets on top of them. ::
 
   $ hg commit -m 'fix bug 17'         # rev 11 (mistake here)
   $ hg commit -m 'cleanup'            # rev 12
@@ -363,12 +363,12 @@
 fixes your mistake. That works, of course, but it makes you look bad:
 you made a mistake, and the record of that mistake is recorded in
 history for all eternity. (If the mistake was in the commit message,
-too bad.)
+too bad: you cannot fix it.)
 
 More subtly, there now exist changesets that are *worse* than what
 came before—the code no longer builds, the tests don't pass, or
-similar. Anyone reviewing these patches will waste time noticing the
-error in the earlier patch, and then the correction later on.
+similar. Anyone reviewing these patches will waste time on the error
+in the earlier patch, and then the correction later on.
 
 You can avoid all this by amending the bad changeset and *evolving*
 subsequent history. Here's how it works, assuming you have just