Convert/Switch to 3-way compare

[mdell-seradex]

I would like to be able to compare two files to some other text, but this currently seems to be difficult to do.
I was thinking that it would be nice to start the compare with two files, and then switch to 3-way compare mode.

In addition, I do find it difficult to use the 3-way merge mode. I was trying to find information on how to use 3-way merge in the help file, but could find very few references to it.
When I use it, I am typically trying to merge changes from one file to another via a common ancestor, but the way it colours things I find makes this difficult. Still it is generally better to see all three files at once instead of in separate comparison screens.

[sambo22]

I think this is similar to what I was thinking:
I'm comparing work in two different branches. I'd like to have the trunk (third folder) included for reference only, but I don't want differences between the trunk and the other branches included in the list of differences.
As mdell-seradex mentioned, it could be a bi-comparison, but when a file is opened for comparison, a third file is opened (trunk, common ancestor, or other reference).

[mdell-seradex]

I forgot to mention that when I do a 3-way compare/merge where one is the common ancestor, I am never sure which pane should contain the ancestor. This was one of the reasons why I was looking in the help file.

[sdottaka]

WinMerge's automatic merging determines the common ancestor depending on the currently active pane, see the link below.

#1156 (comment)

[mdell-seradex]

That feels confusing. It sounds like the pane that is active is treated as the common ancestor. Wouldn't that make controlled merging of changes harder?
To me, the point of a common ancestor is to determine if a change was made in version A or version B. Usually you would want the change to be kept, or perhaps a modified version of it. Sometimes a change was made in both which must be reconciled.
It seems odd to me that the common ancestor would have anything highlighted because it is not a changed version. If it were, then it is NOT a common ancestor.
With that type of merge, I would think that only the changes in versions A and B should be highlighted, or perhaps different colouring is used in the common ancestor to make it clearer. I'm not really sure.
Also, in this case, the common ancestor should never be a floating target based on the selected pane as that defeats its true purpose.
I think it would make more sense, when in that mode (3-way ancestor merge?), to decide that a specific pane (the middle?) is always the common ancestor, or allow the user to choose the common ancestor pane for a set of "files", such that it will not change based on which pane is active (it may be easier for some people if the ancestor is on one side instead of in the middle).
I am probably not describing this perfectly and likely have not thought of all cases.
Perhaps this conversation on common ancestor merging within this issue should be converted to a Discussion?

Note, however that this is a bit off from my original topic.