I see three main thrusts behind the whole proposal, that are each much more significant than any of the specific concrete ideas. The first is that it's time to try some experiments in merge tracking. The second is that restricting merges (primarily to the scope of "a whole branch") is key to reducing complexity and thus both design/implementation error and user error. The third is that we need to make it all much easier to *develop* before we can make much progress.
What we have been doing so far is improving the merge incrementally while trying to keep it at all times backward compatible and almost completely flexible. We have quite a good result now, it is extremely useful in the real world, and we have learned a lot from it. But it has reached the point where it isn't inviting any new development because the bar to entry is much too high. By starting work on something that we call "new", although it may start off as a copy of the old, we avoid the requirement to keep it working, and so make it inviting and feasible to work on. Of course it wouldn't become an official replacement for the old one until it became mature and stable and had some kind of upgrade path, but it would be available as an unofficial alternative for those who want to try it. I think all the suggestions about data format, scripts, eliminating big chunks of code complexity, and so on not hard requirements but simply ideas for how we developers can make it easier for ourselves to understand what's left and try out improvements. And to be able to do that without holding up a 1.8 release until it's "finished". That's the attraction of using either a branch or a parallel subcommand. After reaching this state from which we can go forward, that's when I see the "foreign merges" proposal could be tackled as a possible first extension. Alternatively at that time we might tackle some kind of rename handling or some other improvement. - Julian
