Three-way-merge - different philosophies?

Question

I've been a user of UltraCompare Pro since it first came out, and I think it's a very full-featured compare and merge tool. However, since I have been looking more closely into DVCS, I found that it handles three-way merges differently than (most?) other tools out there. So I wonder why that is, and whether I'm missing something because of it.

In UltraCompare, there are three merge panels (let's call them base, local and other). All the merge action happens within these panels. In practice, this means that I do my work on the middle pane (local), merging changes from the right (other) or maybe from the common ancestor on the left (base). The middle pane is modified during the session and then saved - and committed as the result of the merge. The fourth pane (Output window) only contains information about the diff result.

In other tools, it appears that the three panes only exist in a read-only state, and that the fourth, bottom pane (output) is the place where all the merging happens. What are the reasons to have an extra merge window? Is it easier to keep track of all the changes? Or is it just like that because everybody has always been doing it this way, so we're copying that behavior? What's your opinion on this?

I'm not sure whether there exists a best or correct answer, so I haven't yet made this question CW, but I'll defer to your opinion here as well.

Answer 1

Personally, I like the free perforce merge tool (p4merge). It also has 4 windows - top middle for the original (before branching), left for destination branch, right for source branch and the bottom part is editable.

I like this better than your option 1, as all 3 original files may have important information that can influence the merge.

Answer 2

There are basically two ways to display differences between two files:

• Two panels side by side
• One panel

Graphically:

aaa aaa
bbb ···
··· ccc
ddd ddd

and

 aaa
-bbb
+ccc
 ddd

Some program use the first one (e.g. WinMerge) and some programs allow to choose (e.g. TortoiseMerge or Google Project Hosting). It's probably a matter of taste but I find the second one more intuitive when you want to track changes. However, you need two panels when you want to edit changes.

When doing three-way merges, the different layouts come from this. Ultra compare uses the single panel approach to display changes so you get two panels plus a third panel to edit. Other programs use the two panel approach to display changes so you get three panels plus a fourth one for edits.

Again, I believe it's just a matter of taste.

Answer 3

Seems straightforward to me, you might very well want to keep an unchanged ‘local’ version visible when you are making your changes.

original       local         other           merged

               bar= foo+1    bar= foo+2      bof= foo+2
                                             zot= foo+1
...            ...           ...             ...
print foo      print bar     print foo+1     print bar??

Both local and other have introduced a new variable bar. Merge the first change to bof/zot, go for a cup of tea, come back and try to merge the print. Wait, what was bar in local? If the original local isn't there, that information's gone, and you're scrabbling about with another text editor to work out what's happened.

This is a contrived example but this sort of thing can easily happen for any set of changes you can't keep all in your head and do in one go. In general, a 3WM always has two variable elements, change A and change B. To reproduce all the information in that, you need four views for all the possible permutations of: 0 (the original), A, B, and AB (the merge).