They are missing a pane then. A 3-way merge involves your changes, others changes, a common ancestor, and the resolved text. kdiff3, Beyond Compare, and very recent versions of emacs are the only tools that I've seen that present this properly.
They are missing a pane then. A 3-way merge involves your changes, others changes, a common ancestor, and the resolved text. kdiff3, Beyond Compare, and very recent versions of emacs are the only tools that I've seen that present this properly.
That's true, but is it important to have all those things visible when you're resolving a conflict? The design of a UI should be driven by what the user needs to see, not the data that's being used. Most apps have absolutely loads of invisible data in the background making things work; that doesn't mean they need to be front and centre in the UI.
In my experience of resolving conflicts I can't remember a time when I've needed to refer to the common ancestor, so do I really want to give it screen space?
However, in the end I didn't end up merging any code and I haven't yet been in a position where this has come up much. I just thought it was a funny coincidence I encountered this earlier today.
This is what Araxis Merge did, or at least used to do when I used it, and I found it more useful than P4Merge's 4-way display (which just takes up more space than necessary).
It's possible there are types of merge where it's useful to have the common ancestor permanently visible, but I never seemed to run into them.
If I need a common accessor, I'll pull it up some other way (either via history tools or actually finding it in Github).