diff -r 2cab06f5c4d4 -r 803d32f4e498 docs/user-guide.rst --- 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