On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
...
> I just want to say: I'm not at all demanding we break backward
> compatibility. Sorry if it sounded like it. I'm just saying that we're
> proposing to change the behaviour of the plain merge command, and in doing
> that we need to work out what the details of the new behaviour will be, and
> this thread is helping us to do just that. I ended up with a bias towards
> trying to move toward a more rename-friendly approach, but I recognise we
> can't get there yet so the "follow each node's own ancestry" idea is just an
> idea for the future. We need a simpler approach for now.
I intended to join the discussion when this thread first started, but
never got around to it...
I just wanted to add: it seems to me that for a rename-friendly merge
(rename-friendly accross the entire tree that's being merged), we at
least need to first tackle the problem of handling server-side
renames/moves for 'update' (as 'update' can be seen as a simple
merge-like case). If and when that problem is solved, and we get a
clear understanding of the desired behavior involved, and get more
experience with that, only then can we start thinking about the more
complex situation of 'merge'.
That said, from where I'm sitting "rename-friendly merging" seems
orthogonal to making symmetric merge handle subtree merges. AFAICS,
there is nothing preventing symmetric merge from supporting
"rename-unfriendly subtree merges", just like the current merge code
does. So I think Julian's latest effort, trying to write down some
subtree merging behavior, and then seeing how symmetric merge
can/should handle those, is the best way to go ...
--
Johan
Received on 2012-07-11 14:44:29 CEST