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
Received on 2011-07-12 19:12:58 CEST