On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad <julianf...@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
