# HG changeset patch # User Greg Ward # Date 1428954162 14400 # Node ID 8cc6e90354a9c31c9998051cec800340ee6e50e3 # Parent c94aaf6df69c54dabffe95f9e1914339bb77304f docs: tweak wording, punctuation for better readability diff -r c94aaf6df69c -r 8cc6e90354a9 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