On Tue, Jul 12, 2011 at 1:12 PM, Julian Foad <julian.f...@wandisco.com> wrote: > 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.
+1 > 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. Once again I agree on the complexity, but there seems to be a general understanding that subtree merges/mergeinfo are catastrophically broken; all I'd like is some specifics before we use that as one of the primary reasons for a complete merge revamp. Paul > 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 > > >
