--- 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