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

[Martin von Zweigbergk]

On Nov 8, 2014 3:38 AM, "Mads Kiilerich" <mads at kiilerich.com> wrote:
>
> 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>
wrote:
>>>
>>> # HG changeset patch
>>> # User Mads Kiilerich <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.)

How about a graph in the commit message at least then? Like this before?

---0---1---2
    \   \
     3---4---5

And whatever is the current state after rebase and what you think should be
the right state.

>
>
>>
>>>
>>> +  $ 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.

So what does "remote changed f which local deleted" mean if not that there
is a conflict?

> Rebasing an ancestor merge is in general inherently nonsensical.

In general yes, but for so-called evil merges, there is information that
gets lost (as Pierre-Yves also pointed out). It's a hard problem, though.

>
>
>>
>>>
>>> +  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
>>> http://selenic.com/mailman/listinfo/mercurial-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141108/e818d986/attachment.html>