--- a/docs/user-guide.rst Sat Oct 26 22:43:06 2019 +0700
+++ b/docs/user-guide.rst Sat Oct 26 22:44:06 2019 +0700
@@ -403,7 +403,7 @@
The fix is to *evolve* history::
- $ hg evolve --all
+ $ hg evolve
This is a separate step, not automatically part of ``hg amend``,
because there might be conflicts. If your amended changeset modifies a
@@ -418,7 +418,7 @@
.. figure:: figures/figure-ug07.svg
- Figure 7: evolve your repository (``hg evolve --all``) to take care
+ Figure 7: evolve your repository (``hg evolve``) to take care
of instability. Orphan changesets become obsolete, and are
replaced by successors just like the amended changeset was.
@@ -450,14 +450,14 @@
As before, the solution to orphan changesets is to evolve your
repository::
- $ hg evolve --all
+ $ hg evolve
This rebases revision 20 on top of 18 as the new revision 21, leaving
19 and 20 obsolete and hidden:
.. figure:: figures/figure-ug09.svg
- Figure 9: once again, ``hg evolve --all`` takes care of instability.
+ Figure 9: once again, ``hg evolve`` takes care of instability.
Example 9: Uncommit files from an older changeset (discard changes)
=======================================================================
@@ -491,7 +491,7 @@
hack, so we can discard it and immediately evolve the instability away::
$ hg revert file2.c
- $ hg evolve --all
+ $ hg evolve
move:[23] fix bug 67
atop:[24] fix bug 53
@@ -545,7 +545,7 @@
This is where things get tricky. As usual when a repository has
orphan changesets, we want to evolve it::
- $ hg evolve --all
+ $ hg evolve
The problem is that ``hg evolve`` rebases revision 27 onto revision
28, creating 30 (the successor of 27). This is entirely logical: 27