root-ids changing for some merges

[Aaron Bentley]

On 05/07/2011 2:48 PM, vila wrote:
>>>>>> Aaron Bentley<aaron at aaronbentley.com>  writes:
>
>      >  On 11-07-05 12:38 PM, vila wrote:
>      >>  The drawback that I just realized is that it breaks 'merge -r0..nn
>      >>  ../unrelated-branch' by forcing the new root which in turn trigger a
>      >>  rename for all existing children of the old root
>
>      >  That is the expected behaviour.
>
> It wasn't the behaviour *before* your patch, the root-id was preserved
> and the existing files in THIS weren't renamed.

This is true, but most branches do change behaviour.  I pointed this 
change out when I proposed the merge, so by approving the proposal, 
Jelmer approved the change in behaviour.

What's much more interesting is what behaviour do we want, and why?

I felt that since there's a tie to break (a tree can't have two roots), 
it made a lot of sense to break the tie in favour of OTHER, since that's 
how merge usually breaks ties.

You clearly prefer the old behaviour, so I'd like to know why.

>      >  Could you explain why that is a drawback?
>
> Seeing all the files present in the branch before the merge being
> renamed to the same name is quite surprising.

Okay, so there's bad UI consequences.  Anything else?

> May be my test case is wrong and falsely alarming, yet, it passed on 2.2
> and 2.3 but fails on trunk. Did you look at it ?

No.  I couldn't parse what you were saying.

Aaron