[PATCH 1 of 2 stable] tests: add test for rebasing merges with ancestors of the rebase destination

[Mads Kiilerich]

On 11/08/2014 06:36 AM, Martin von Zweigbergk wrote:
>
>
> On Fri Nov 07 2014 at 5:28:28 PM Mads Kiilerich <mads at kiilerich.com 
> <mailto:mads at kiilerich.com>> wrote:
>
>     # HG changeset patch
>     # User Mads Kiilerich <madski at unity3d.com <mailto:madski at unity3d.com>>
>     # Date 1415409335 -3600
>     #      Sat Nov 08 02:15:35 2014 +0100
>     # Branch stable
>     # Node ID 8f689654b7d3d6b7c2b370cd5e38198b625e4fc6
>     # Parent  c35ffa4249cab47a1e089a30bc16fc65a0727f48
>     tests: add test for rebasing merges with ancestors of the rebase
>     destination
>
>     This shows sub-optimal behaviour. The user get a merge prompt that
>     is very hard
>     to explain.
>
>
> It seems more like you want the feature to work differently than it 
> currently does than a bug (I'm wondering if the "stable" flag is 
> appropriate). It's not obvious what the right behavior is. With the 
> suggestions below, it might be easier to tell what this is about.

The test shows behaviour that doesn't make sense and is wrong. That is a 
bug. A bug that in some cases would give wrong results when rebasing. I 
thus think a fix on stable is appropriate.

>
>
>     diff --git a/tests/test-rebase-newancestor.t
>     b/tests/test-rebase-newancestor.t
>     --- a/tests/test-rebase-newancestor.t
>     +++ b/tests/test-rebase-newancestor.t
>     @@ -53,3 +53,42 @@
>
>
>        $ cd ..
>     +
>     +
>     +Test rebasing of merges with ancestors of the rebase destination
>     - a situation
>     +that often happens when trying to rebase instead of repeated merges.
>     +
>     +  $ hg init repo2
>     +  $ cd repo2
>     +  $ touch f
>     +  $ hg ci -Aqm 'f'
>     +  $ echo stuff > f
>     +  $ hg ci -m 'f stuff'
>     +  $ hg rm f
>     +  $ hg ci -m 'remove f'
>     +  $ hg up -qr0
>     +  $ hg branch -q dev
>     +  $ hg ci -qm 'dev'
>     +  $ hg merge -q 1
>     +  $ hg ci -m 'merge f stuff'
>     +  $ hg merge -q 2
>     +  $ hg ci -m 'merge remove f'
>     +  $ touch devstuff
>     +  $ hg ci -Aqm 'real dev stuff'
>
>
> A graph log at this point would make the history clear. Now the reader 
> has to create that graph in their head.

I can add it. The graph is as big as the commands for creating the case 
and it doesn't look that nice. (I could create the test case in a more 
complicated way and make the graph looks nicer. Meh.)

>     +  $ hg rebase -r 'branch(dev)' -d default
>     +  remote changed f which local deleted
>     +  use (c)hanged version or leave (d)eleted? c
>     +  local changed f which remote deleted
>     +  use (c)hanged version or (d)elete? c
>
>
> The conflicts just seem like distraction. Would you be able to 
> demonstrate the same behavior without conflicts?

Look at the test case. f is never touched in the changes we rebase. 
There _is_ no conflict. Rebasing an ancestor merge is in general 
inherently nonsensical.

>     +  saved backup bundle to
>     $TESTTMP/repo2/.hg/strip-backup/*-backup.hg (glob)
>     +  $ hg tglog
>     +  @  4: 'real dev stuff'
>     +  |
>     +  o  3: 'merge f stuff'
>     +  |
>     +  o  2: 'remove f'
>     +  |
>     +  o  1: 'f stuff'
>     +  |
>     +  o  0: 'f'
>     +
>     _______________________________________________
>     Mercurial-devel mailing list
>     Mercurial-devel at selenic.com <mailto:Mercurial-devel at selenic.com>
>     http://selenic.com/mailman/listinfo/mercurial-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141108/9e94f91e/attachment.html>