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

[Mads Kiilerich]

On 11/08/2014 07:11 PM, Martin von Zweigbergk wrote:
> >>> +  $ 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?
>

It is garbage in garbage out. It is using an invalid merge ancestor and 
thus getting a result that doesn't make sense. Also, there _is_ no 
correct ancestor. The problem is thus not that it is using a wrong 
ancestor but that it is trying to merge.

> > 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).
>

That information will be lost anyway if the user has to dig it out among 
a lot of misleading and wrong information.

/Mads