Switch from 3 way to 2 way (and back)

[buckley]

I am in a situation where a 3 way merge is useful most of the time but sometimes I need to switch to the 2 way view.

Is this possible from the gui?

Kr, Tom

[Aaron]

Hello,

You can hide the center pane or detach the output pane from the View menu. You can also use the Session menu to Compare Output pane to (Specific Side) to launch a new tab comparing the output to the target.

[zartc]

Hello,

Sorry to "kind of" hijack the thread but I have a question that is related to buckley's one.

=> I am in a situation (resolving svn merge conflics) where a 3 way merge is useful most of the time but sometimes I need to switch to a 2 way view, comparing the CENTER pane (the ancestor revision in SVN) with the RIGHT pane (the last revision in SVN) or the LEFT pane (my file not yet commited). Is it possible from the gui?

The Compare Output pane will no do it because it always compare with the output pane.

Thank in advance.
ZartC.

[Aaron]

Hello,

With the main top 3 panes already aligned from Left to Center and Right to Center, you could switch the Display Filter to "Show Right Changes" to then concentrate on just the Center <-> Right comparison.

[TrueWill]

I have a similar issue. I'm using Git on Windows with BC Pro. 99% of the time seeing BASE isn't useful. What I really want is to hide BASE (or even kill it altogether in .gitconfig) and see the differences between LOCAL and REMOTE. How can I do this?

[Aaron]

Hello,

The View menu -> Center Pane can hide the center information.

The Center should be the common Ancestor of the Left and Right sides, and is often very useful for determining conflict status. Most Version Control Software's core logic revolves around the existence of the Ancestor and History. Without an Ancestor, every difference is an equally weighted conflict and every change must be manually reviewed. With an Ancestor, users can determine which side has been edited since their last checkout by themselves or others, so they can more quickly review and accept differences where the other party has not edited the same section of code.

[lion]

Sorry to revive this thread but i am having the exact same question as TrueWill and couldn't find any answer.

I'm totally with that the statements about a common ancestor, but in some cases, f.e. when people manually merged stuff, the result is that local and remote changes are almost identical but both diverge massively from their common ancestor. It is then when ignoring the common ancestor would be very beneficial.

In a case i'm just having comparing local (the current branch) with remote (the branch to be merged into local) shows one different line, but both have the same > 50 differences with the common ancestor.

I'm working with tortoiseGit which creates three files before invoking beyond compare:
- xx.yy.BASE.yy (the common ancestor [left])
- xx.yy.LOCAL.yy (the current branch [center])
- xx.yy.REMOTE.yy (the branch which is merged into the current branch [right])

What i can do is to manually start a two way beyond compare comparison for the temporary files "xx.yy.LOCAL.yy" and "xx.yy.REMOTE.yy" while ignoring "xx.yy.BASE.yy", merge into "xx.yy.LOCAL.yy", overwrite "target xx.yy" with xx.yy.LOCAL.yy", abort the three way merge and manually delete "xx.yy.LOCAL.yy", "xx.yy.REMOTE.yy" and "xx.yy.BASE.yy".

But that's a lot of work.
Is there an easier way to do this?

[Aaron]

Hello,

The Common Ancestor must be in the Center pane for the Merge logic to work correctly.

I'd suggest updating the TortoiseGit configuration so that it can call as such, as then any change commonly diverged (say, the left and right have the same change from the center) would be taken automatically, and any Changed on One side (where the other side matches the ancestor) would be taken automatically. Only sections that conflict (where the left and right are both changed and different from each other) present as conflicts to resolve in the output.

If it is out of order, I suspect a lot more content is marked as a conflict, which would make it much more difficult to form the Output.

We have a KB article about defining VCS for TortoiseGit here:
https://www.scootersoftware.com/supp...cs#tortoisegit

With this in place, does that make the interface more intuitive and work better at auto-generating the Output? You can also use the View menu to Favor the Left or Right side changes so that they are still taken, but aren't marked with a color in the output, making it easier to read if you Favor a specific side and don't need to review it.