diff docs/user-guide.rst @ 4618:803d32f4e498

docs: change `unstable` references to `orphan`

Per https://www.mercurial-scm.org/wiki/CEDVocabulary

--- a/docs/user-guide.rst	Sat Apr 27 21:09:47 2019 -0400
+++ b/docs/user-guide.rst	Sat Apr 27 21:24:18 2019 -0400
@@ -336,7 +336,7 @@
 So far, every obsolete changeset we have seen is also hidden. However,
 these are *not* the same thing—that's why they have different names.
 It's entirely possible to have obsolete changesets that are not
-hidden. We'll see examples of that soon, when we create *unstable*
+hidden. We'll see examples of that soon, when we create *orphan*
 changesets.
 
 Note that all hidden changesets are obsolete: hidden is a subset of
@@ -349,10 +349,10 @@
 
 Now that you've got a solid understanding of how ``evolve`` works in
 concert with changeset obsolescence, let's explore some more advanced
-scenarios. All of these scenarios will involve *unstable* changesets,
+scenarios. All of these scenarios will involve *orphan* changesets,
 which is an unavoidable consequence of obsolescence. What really sets
 ``evolve`` apart from other history modification mechanisms is the
-fact that it recognizes instability like unstable changesets and provides
+fact that it recognizes instability like orphan changesets and provides
 a consistent way for you to get back to a stable repository.
 
 (Incidentally, there are two other types of instability that changesets
@@ -393,17 +393,17 @@
   $ hg amend
 
 At this point, revision 11 is *obsolete* and revisions 12 and 13—the
-descendants of 11—are in a funny state: they are *unstable*.
+descendants of 11—are in a funny state: they are *orphan*.
 
 .. figure:: figures/figure-ug06.svg
 
    Figure 6: amending a changeset with descendants means the amended
    changeset is obsolete but remains visible; its non-obsolete
-   descendants are *unstable*. The temporary amend commit, revision
+   descendants are *orphan*. The temporary amend commit, revision
    14, is hidden because it has no non-obsolete descendants.
 
 All non-obsolete descendants of an obsolete changeset are considered
-unstable. An interesting consequence of this is that revision 11 is
+orphans. An interesting consequence of this is that revision 11 is
 still visible, even though it is obsolete. Obsolete changesets with
 non-obsolete descendants are not hidden.
 
@@ -425,7 +425,7 @@
 .. figure:: figures/figure-ug07.svg
 
    Figure 7: evolve your repository (``hg evolve --all``) to take care
-   of instability. Unstable changesets become obsolete, and are
+   of instability. Orphan changesets become obsolete, and are
    replaced by successors just like the amended changeset was.
 
 Example 8: Prune an older changeset
@@ -441,19 +441,19 @@
 
   $ hg prune 19
   1 changesets pruned
-  1 new unstable changesets
+  1 new orphan changesets
 
 As above, this leaves your repository in a funny intermediate state:
 revision 20 is the non-obsolete descendant of obsolete revision 19.
-That is, revision 20 is unstable.
+That is, revision 20 is an orphan.
 
 .. figure:: figures/figure-ug08.svg
 
    Figure 8: ``hg prune`` marks a changeset obsolete without creating
    a successor. Just like with ``hg amend``, non-obsolete descendants
-   of the pruned changeset are now unstable.
+   of the pruned changeset are now orphans.
 
-As before, the solution to unstable changesets is to evolve your
+As before, the solution to orphan changesets is to evolve your
 repository::
 
   $ hg evolve --all
@@ -485,11 +485,11 @@
   $ hg update 22
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ hg uncommit file2.c
-  1 new unstable changesets
+  1 new orphan changesets
   $ hg status
   M file2.c
 
-Now your repository has unstable changesets, so you need to evolve it.
+Now your repository has orphan changesets, so you need to evolve it.
 However, ``hg evolve`` requires a clean working directory to resolve merge
 conflicts, so you need to decide what to do with ``file2.c``.
 
@@ -530,7 +530,7 @@
   $ hg update -q 26
   1 files updated, 0 files merged, 0 files removed, 0 files unresolved
   $ hg uncommit -q file2.c  # obsoletes rev 26, creates rev 28
-  1 new unstable changesets
+  1 new orphan changesets
   $ hg status
   M file2.c
 
@@ -541,7 +541,7 @@
 Figure 11 shows the story so far: ``uncommit`` obsoleted revision 26
 and created revision 28, the successor of 26. Then we committed
 revision 29, a child of 28. We still have to deal with the revision 27,
-which is an unstable changeset.
+which is an orphan changeset.
 
 .. figure:: figures/figure-ug11.svg
 
@@ -549,7 +549,7 @@
    separately will soon result in a two-headed repository.
 
 This is where things get tricky. As usual when a repository has
-unstable changesets, we want to evolve it::
+orphan changesets, we want to evolve it::
 
   $ hg evolve --all
 
@@ -561,7 +561,7 @@
 
 .. figure:: figures/figure-ug12.svg
 
-   Figure 12: ``evolve`` takes care of unstable changesets; it does
+   Figure 12: ``evolve`` takes care of orphan changesets; it does
    not solve all the world's problems.
 
 As usual when faced with a two-headed repository, you can either merge
@@ -594,7 +594,7 @@
 change in the future. Consider the history in Figure 12, where revision 27
 is obsolete and the child of 26, also obsolete. If we ``hg touch 27``, that
 creates a new revision which is a non-obsolete child of 26—i.e., it is an
-unstable. It's also *divergent*, another type of trouble that we'll learn
+orphan. It's also *divergent*, another type of trouble that we'll learn
 about in the `next section`_.
 
 .. _`next section`: sharing.html