Mercurial > evolve
changeset 1267:8cc6e90354a9 stable
docs: tweak wording, punctuation for better readability
| author | Greg Ward <greg@gerg.ca> |
|---|---|
| date | Mon, 13 Apr 2015 15:42:42 -0400 |
| parents | c94aaf6df69c |
| children | ba3ff8c00304 |
| files | docs/user-guide.rst |
| diffstat | 1 files changed, 7 insertions(+), 7 deletions(-) [+] |
line wrap: on
line diff
--- 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