diff -r 1765fd925fc1 -r 3874bc10d4a7 docs/sharing.rst --- 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