--- a/docs/sharing.rst Mon Nov 11 02:33:54 2019 +0700
+++ b/docs/sharing.rst Mon Nov 11 02:42:37 2019 +0700
@@ -181,16 +181,24 @@
punctuation and capitalization (oops). Let's amend our preliminary fix
(and fix the lame commit message while we're at it)::
+ $ echo 'Fix fix fix' > file1
+ $ hg amend -m 'fix bug 37'
+
+For the sake of illustrating how obsolete changesets are not exchanged, let's
+amend again::
+
$ echo 'Fix fix fix.' > file1
$ hg amend -m 'fix bug 37'
+Note: some time ago, evolve used to create temporary amend commits. Here,
+amending twice in a row is reminiscent of that behaviour that you may have seen
+in older tutorials.
+
Now we're in a funny intermediate state (figure 2): revision 1:f649 is
-obsolete in ``test-repo``, having been replaced by revision 3:60ff
-(revision 2:2a03 is another one of those temporary amend commits that
-we saw in the user guide)—but ``dev-repo`` knows nothing of these
-recent developments.
+obsolete in ``test-repo``, having been replaced by revision 2:96d8 and then by
+3:522d—but ``dev-repo`` knows nothing of these recent developments.
- [figure SG02: test-repo has rev 0:0dc9 public, rev 1:f649, 2:2a03 obsolete, rev 3:60ff draft; dev-repo same as in SG01]
+ [figure SG02: test-repo has rev 0:0dc9 public, rev 1:f649 and 2:96d8 obsolete, rev 3:522d draft; dev-repo same as in SG01]
Let's resynchronize::
@@ -202,11 +210,10 @@
As seen in figure 3, this transfers the new changeset *and* the
obsolescence marker for revision 1. However, it does *not* transfer
-the temporary amend commit, because it is hidden. Push and pull
-transfer obsolescence markers between repositories, but they do not
-transfer hidden changesets.
+2:96d8, because it is hidden. Push and pull transfer obsolescence
+markers between repositories, but they do not transfer hidden changesets.
- [figure SG03: dev-repo grows new rev 2:60ff, marks 1:f649 obsolete]
+ [figure SG03: dev-repo grows new rev 2:522d, marks 1:f649 obsolete]
Because of this deliberately incomplete synchronization, revision
numbers in ``test-repo`` and ``dev-repo`` are no longer consistent. We
@@ -220,11 +227,13 @@
less-than-perfect idea. We'll implement it locally in ``dev-repo`` and
push to ``test-repo``::
+ $ echo 'Fix, fix, and fix' > file1
+ $ hg amend
$ echo 'Fix, fix, and fix.' > file1
$ hg amend
$ hg push
-This time around, the temporary amend commit is in ``dev-repo``, and
+This time around, the first amend commit stays in ``dev-repo``, and
it is not transferred to ``test-repo``—the same as before, just in the
opposite direction. Figure 4 shows the two repositories after amending
in ``dev-repo`` and pushing to ``test-repo``.
@@ -244,7 +253,7 @@
[...]
added 1 changesets with 1 changes to 1 files
-Note that only one changeset—the final version, after two
+Note that only one changeset—the final version, after all the
amendments—was actually pushed. Again, Mercurial doesn't transfer
hidden changesets on push and pull.
@@ -254,12 +263,12 @@
``dev-repo`` or ``test-repo``. Neither of our missteps nor our amendments
are publicly visible, just the final, beautifully polished changeset:
- [figure SG05: public repo with rev 0:0dc9, 1:de61, both public]
+ [figure SG05: public repo with rev 0:0dc9, 1:7b49, both public]
There is one important step left to do. Because we pushed from
``test-repo`` to ``public``, the pushed changeset is in *public* phase
in those two repositories. But ``dev-repo`` has been out-of-the-loop;
-changeset de61 is still *draft* there. If we're not careful, we might
+changeset 7b49 is still *draft* there. If we're not careful, we might
mutate history in ``dev-repo``, obsoleting a changeset that is already
public. Let's avoid that situation for now by pushing up to
``dev-repo``::
@@ -385,7 +394,7 @@
Figure 6 shows the state of the ``review`` repository at this point.
- [figure SG06: rev 2:f91e is Alice's obsolete v1, rev 3:cbdf is her v2; both children of rev 1:de61]
+ [figure SG06: rev 2:4e96 is Alice's obsolete v1, rev 3:3363 is her v2; both children of rev 1:7b49]
After a busy morning of bug fixing, Alice stops for lunch. Let's see
what Bob has been up to.
@@ -401,7 +410,7 @@
$ cd ../bob
$ echo 'stuff' > file1
$ hg bookmark featureX
- $ hg commit -u bob -m 'implement feature X (v1)' # rev 4:1936
+ $ hg commit -u bob -m 'implement feature X (v1)' # rev 4:c7ff
$ hg push -B featureX
[...]
added 1 changesets with 1 changes to 1 files (+1 heads)
@@ -411,7 +420,7 @@
bit, amends, and submits the resulting changeset for review::
$ echo 'do stuff' > file1
- $ hg amend -m 'implement feature X (v2)' # rev 5:0eb7
+ $ hg amend -m 'implement feature X (v2)' # rev 5:1bb4
$ hg push
[...]
added 1 changesets with 1 changes to 1 files (+1 heads)
@@ -421,7 +430,7 @@
on proper capitalization and punctuation. ::
$ echo 'Do stuff.' > file1
- $ hg amend -m 'implement feature X (v3)' # rev 6:540b
+ $ hg amend -m 'implement feature X (v3)' # rev 6:9d21
On the bright side, the second review said, "Go ahead and publish once
you fix that." So Bob immediately publishes his third attempt::
@@ -432,8 +441,8 @@
It's not enough just to update ``public``, though! Other people also
use the ``review`` repository, and right now it doesn't have Bob's
-latest amendment ("v3", revision 6:540b), nor does it know that the
-predecessor of that changeset ("v2", revision 5:0eb7) is obsolete. Thus,
+latest amendment ("v3", revision 6:9d21), nor does it know that the
+predecessor of that changeset ("v2", revision 5:1bb4) is obsolete. Thus,
Bob pushes to ``review`` as well::
$ hg push ../review
@@ -463,9 +472,9 @@
$ hg push ../public
[...]
- remote has heads on branch 'default' that are not known locally: 540ba8f317e6
- abort: push creates new remote head cbdfbd5a5db2!
- (pull and merge or see "hg help push" for details about pushing new heads)
+ remote has heads on branch 'default' that are not known locally: 9d21d673314a
+ abort: push creates new remote head 3363442626b3 with bookmark 'bug15'!
+ (pull and merge or see 'hg help push' for details about pushing new heads)
Oops! Bob has won the race to push first to ``public``. So Alice needs
to integrate with Bob: let's pull his changeset(s) and see what the
@@ -476,9 +485,9 @@
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg log -G -q -r 'head()' --template '{rev}:{node|short} ({author})\n'
- o 5:540ba8f317e6 (bob)
+ o 4:9d21d673314a (bob)
|
- | @ 4:cbdfbd5a5db2 (alice)
+ | @ 3:3363442626b3 (alice)
|/
We'll assume Alice and Bob are perfectly comfortable with rebasing
@@ -486,7 +495,7 @@
form of ``amend``.) So Alice rebases her changeset on top of Bob's and
publishes the result::
- $ hg rebase -d 5
+ $ hg rebase -d 4
$ hg push ../public
[...]
added 1 changesets with 1 changes to 1 files
@@ -567,7 +576,7 @@
$ cd bob
$ echo 'pretty good fix' >> file1
- $ hg commit -u bob -m 'fix bug 24 (v1)' # rev 4:2fe6
+ $ hg commit -u bob -m 'fix bug 24 (v1)' # rev 4:b2be
Since Alice and Bob are now in cowboy mode, Alice pulls Bob's draft
changeset and amends it herself. ::
@@ -584,10 +593,10 @@
$ cd ../bob
$ echo 'better fix (bob)' >> file1
- $ hg amend -u bob -m 'fix bug 24 (v2 by bob)' # rev 6:a360
+ $ hg amend -u bob -m 'fix bug 24 (v2 by bob)' # rev 5:541f
At this point, the divergence exists, but only in theory: Bob's
-original changeset, 4:2fe6, is obsolete and has two successors. But
+original changeset, 4:b2be, is obsolete and has two successors. But
those successors are in different repositories, so the trouble is not
visible to anyone yet. It will be as soon as Bob pulls from Alice's
repository (or vice-versa). ::
@@ -600,20 +609,20 @@
Figure 9 shows the situation in Bob's repository.
- [figure SG09: Bob's repo with 2 heads for the 2 content-divergent changesets, 6:a360 and 7:e3f9; wc is at 6:a360; both are successors of obsolete 4:2fe6, hence divergence]
+ [figure SG09: Bob's repo with 2 heads for the 2 content-divergent changesets, 5:541f and 6:e3a5; wc is at 5:541f; both are successors of obsolete 4:b2be, hence divergence]
Now we need to get out of trouble. As usual, the answer is to evolve
history. ::
$ HGMERGE=internal:other hg evolve
- merge:[6] fix bug 24 (v2 by bob)
- with: [7] fix bug 24 (v2 by alice)
+ merge:[5] fix bug 24 (v2 by bob)
+ with: [6] fix bug 24 (v2 by alice)
base: [4] fix bug 24 (v1)
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
Figure 10 shows how Bob's repository looks now.
- [figure SG10: only one visible head, 9:b149, successor to hidden 6:a360 and 7:e3f9]
+ [figure SG10: only one visible head, 7:aa82, successor to hidden 5:541f and 6:e3a5]
We carefully dodged a merge conflict by specifying a merge tool
(``internal:other``) that will take Alice's changes over Bob's. (You