On Tue, Jul 12, 2011 at 1:12 PM, Julian Foad <julian.foad_at_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
>
>
>
Received on 2011-07-12 19:50:23 CEST