[PATCH 2 of 2 stable] rebase: handle rebasing of merges of destination ancestors

[Mads Kiilerich]

On 11/08/2014 06:38 AM, Martin von Zweigbergk wrote:
>
>
> On Fri Nov 07 2014 at 5:28:34 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 1415409531 -3600
>     #      Sat Nov 08 02:18:51 2014 +0100
>     # Branch stable
>     # Node ID 4f80b7a3cdf219d1c8e5b3a7f2d539cd035cf8c4
>     # Parent  8f689654b7d3d6b7c2b370cd5e38198b625e4fc6
>     rebase: handle rebasing of merges of destination ancestors
>
>     A situation with several merges from another branch can be
>     'straightened out'
>     by rebasing (or grafting) on top of the other branch. One problem
>     is merges
>     that merges an ancestor of the rebase destination. Graft will skip
>     such merges
>     as 'ungraftable merge revision'. Rebase would try to rebase them
>     ... and could
>     fail.
>
>     Now, the problem is solved by skipping such ancestor merges when
>     rebasing.
>

>     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
>     @@ -76,15 +76,11 @@ that often happens when trying to rebase
>        $ touch devstuff
>        $ hg ci -Aqm 'real dev stuff'
>        $ 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
>     +  4 is merging 1 which is an ancestor of the rebase target and is
>     ignored
>     +  5 is merging 2 which is an ancestor of the rebase target and is
>     ignored
>        saved backup bundle to
>     $TESTTMP/repo2/.hg/strip-backup/*-backup.hg (glob)
>        $ hg tglog
>     -  @  4: 'real dev stuff'
>     -  |
>     -  o  3: 'merge f stuff'
>     +  @  3: 'real dev stuff'
>
>
> It looks like the commit that creates the dev branch still gets lost. 
> Is that desirable? I don't see why it would be.

The test is not using --keepbranches so when the 'dev' changeset is 
rebased, it do nothing. One of the benefits of rebase is that it removes 
empty changesets - for instance when a change has been grafted to occur 
on both sides or when merging with an ancestor. It is thus correct 
behaviour that the branch creation changeset goes away.

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