Recursive merge strategy

[psantosl]

Hi,

> > Indeed. But you shouldn't judge the situation from this blog post as
> > it's not coherent.
>
> Thanks for debunking this. I've added a comment with link back to your
> mail. It's currently in moderation... but I hope the author will let it
> go through.

Yes, it is already published.

I'm the author of the blog post and co-founder at Plastic SCM
(www.plasticscm.com), and happy to discuss about the recursive merge
implementation.

I'll clarify the nonsense comments first, and later I'll discuss the
technical details, ok?

Let's go:

> This seems to be yet another instance of "Git is incomprehensible,
> therefore Git is magic, therefore Git magically works better" logic at
> work.

Funny comment, but unfortunately you're wrong: we've implemented our
own 'recursive merge' so I'm afraid "magic and incomprehensible" is
not an option. I wrote this blog post trying to share what we learnt
while implementing our new merge system in plastic 4.0.

> Let's _actually_ work his original example diagram which has the
> criss-crossing merges (which I guess he copied from someone who knew
> what they were talking about).

Thanks!

> I'm going to ignore the blogger's nonsensical use of arrows that
> point the wrong way for branch merges and thus add cycles into
> the "directed acyclic graph".

We render arrows to 'parent changesets' but we also render (and
track!) merge-links separately. We always rendered merges in "source
to destination" direction, and we keep the same style in our newest
release, and that's why I keep drawing them this way. It is a matter
of preference but I simply find "merge arrows" simpler to understand
when they go from "merge source" to "merge destination". That's all.
Saying they're "nonsensical" and "point to the wrong direction"
doesn't give you a better position to talk about SCM, I'm afraid.

That being said, if it is fine for you, I'll come back with a in-depth
explanation about the merge algorithm itself.

Regards,

Pablo Santos
www.plasticscm.com