--- a/docs/sharing.rst	Sat Apr 27 21:41:04 2019 -0400
+++ b/docs/sharing.rst	Sat Apr 27 21:54:52 2019 -0400
@@ -513,7 +513,7 @@
 non-obsolete changeset with obsolete ancestors is an orphan.)
 
 Two other types of instability can happen: *content-divergent* and
-*bumped* changesets. Both are more likely with shared mutable
+*phase-divergent* changesets. Both are more likely with shared mutable
 history, especially mutable history shared by multiple developers.
 
 Setting up
@@ -686,16 +686,16 @@
 obsolete, it made perfect sense for it to have a successor, namely
 Bob's amendment of Alice's fix (changeset 4:fe88). But it's illogical
 for a public changeset to have a successor, so 4:fe88 is unstable:
-it has become *bumped*.
+it has become *phase-divergent*.
 
-  [figure SG07: 2:e011 now public not obsolete, 4:fe88 now bumped]
+  [figure SG07: 2:e011 now public not obsolete, 4:fe88 now phase-divergent]
 
 As usual when there's trouble in your repository, the solution is to
 evolve it::
 
   $ hg evolve --all
 
-Figure 8 illustrates Bob's repository after evolving away the bumped
+Figure 8 illustrates Bob's repository after evolving away the phase-divergent
 changeset. Ignoring the obsolete changesets, Bob now has a nice,
 clean, simple history. His amendment of Alice's bug fix lives on, as
 changeset 5:227d—albeit with a software-generated commit message. (Bob
@@ -703,7 +703,7 @@
 But the important thing is that his repository no longer has any
 unstable changesets, thanks to ``evolve``.
 
-  [figure SG08: 5:227d is new, formerly bumped changeset 4:fe88 now hidden]
+  [figure SG08: 5:227d is new, formerly phase-divergent changeset 4:fe88 now hidden]
 
 Conclusion
 ----------