diff tests/test-prev-next.t @ 4252:a07cd1d076bb

next: solve the issue of `next` get confused by split

This patch solve a problem of next command which get confused by split.
Let me describe how it was getting confused:

Initial state of repo:

      A---B---C

After splitting B to (B1,B2):

          @
      A---B1---B2
       \
        ---B---C
           X   *

    (note: C is orphan; checkedout to B1)

Lets make an amend on B1:

            @
            B1'
           /
      A---B1---B2
       \  X    *
        \
         ---B---C
            X   *

Now, if run `hg next` (--evolve is True by default now):

$ it would give you choice to choose from B2 and C thinking that C could also
  be a possbile children for B1, instead of stablizing B2 on B1.

I fixed this problem by filtering those aspiring children which can be
stablized on one of the aspiring children itself.

Changes made in test-prev-next.t shows the changed expected behaviour.

--- a/tests/test-prev-next.t	Tue Nov 06 15:10:56 2018 +0530
+++ b/tests/test-prev-next.t	Tue Nov 06 10:41:50 2018 +0530
@@ -484,8 +484,8 @@
   use 'hg resolve' to retry unresolved file merges
   [2] added bar
 
-Add test which shows that `next` command get confused by split:
----------------------------------------------------------------
+Add test which shows that now `next` command does not get confused by split:
+----------------------------------------------------------------------------
   $ cd ..
   $ mkdir nextconfused
   $ cd nextconfused
@@ -584,13 +584,6 @@
   $ hg next --evolve << EOF
   > q
   > EOF
-  ambiguous next (unstable) changeset, choose one to evolve and update:
-  0: [fdc998261dcb] C
-  1: [279f6cab32b5] B
-  q: quit the prompt
-  enter the index of the revision you want to select: q
-  ambiguous next (unstable) changeset:
-  [2] C
-  [4] B
-  (run 'hg evolve --rev REV' on one of them)
-  [1]
+  move:[4] B
+  atop:[5] B modified
+  working directory now at 1b434459c7e7