Hello everyone, I'm currently working on the commons-diff-api to add new capabilities in case of conflict. Yesterday while I was working on it, I added new tests to check my changes and discovered that our current implementation of the 3-way merge was not following a "standard" implementation, and so some expectations I could have was not followed. Actually Thomas did a huge job by implementing by himself the 3-way merge based on the diff of previous-current and previous-next, but AFAIU this implementation does not take into account the diff current-next which can also bring information. So for example if you try to do a merge, with the following lines: origin="Once upon a time","a wolf","started to walk","in the forest" next="Once upon a time","a wolf","dressed in black","in the forest" current="Once upon a time","a wolf","started to walk","dressed in black","in the forest" the current result will be: "Once upon a time", "a wolf", "dressed in black", "dressed in black", "in the forest" instead of treating it like a conflict which can be view as a more "standard" answer. Here by standard, I mean the result that a tool like "diff3" or git merge would do. I dig a bit on internet yesterday and apparently diff3 is really considered as the standard implementation of a 3-way merge. I performed the check with those lines both using git and diff3 and in both cases, they see the "started to walk" as a conflictual line: Once upon a time a wolf <<<<<<< HEAD started to walk =======

...

...

...

...

...

> 20b7776... My change dressed in black in the forest

I assume we could debug the implementation Thomas done to ensure this usecase is taken into account, as far as I can see it's not easy, but I guess it's possible. Another solution, which I personally prefer, would be to rely on an existing implementation of a diff3 merge, or Git merge: I found yesterday that jgit have their own Java implementation of the merge (https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse...) and AFAICS the license doesn't prevent us to reuse it (it's a derived BSD license). I don't think we cannot completely reuse it as it is, but it's at least a good inspiration to do our own implementation based on a standard. A better solution would certainly to use a dedicated maintained library but I did not manage to find it. Now we could also assume that the current behaviour of the merge is what we want and we keep up with it. So what do you think, should we change our implem or keep it like that? Simon -- Simon Urli Software Engineer at XWiki SAS [email protected] More about us at http://www.xwiki.com