Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool

[Kevin Bracey <kevin@bracey.fi>]

On 07/03/2013 09:23, Junio C Hamano wrote:
> If p4merge GUI labels one side clearly as "theirs" and the other 
> "ours", and the way we feed the inputs to it makes the side that is 
> actually "ours" appear in p4merge GUI labelled as "theirs", then I do 
> not think backward compatibility argument does not hold water. It is 
> just correcting a longstanding 3-4 year old bug in a tool that nobody 
> noticed.

It's not quite that clear-cut. Some years ago, and before p4merge was 
added as a Git mergetool, P4Merge was changed so its main GUI text says 
"left" and "right" instead of "theirs" and "ours" when invoked manually.

But it appears that's as far as they went. It doesn't seem any of its 
asymmetric diff display logic was changed; it works better with ours on 
the right, and the built-in help all remains written on the theirs/ours 
basis. And even little details like the icons imply it (a square for the 
base, a downward-pointing triangle for their incoming stuff, and a 
circle for the version we hold).

> For people who are very used to the way p4merge shows the merged
> contents by theirs-base-yours order in side-by-side view, I do not
> think it is unreasonable to introduce the "mergetool.$name.reverse"
> configuration variable and teach the mergetool frontend to pay
> attention to it.  That will allow them to see their merge in reverse
> order even when they are using a backend other than p4merge.
>
> With such a mechanism in place, by default, we can just declare that
> mergetool.p4merge.reverse is "true" when unset, while making
> mergetool.$name.reverse for all the other tools default to "false".
> People who are already used to the way our p4merge integration works
> can set mergetool.p4merge.reverse to "false" explicitly to retain
> the historical behaviour that you are declaring "buggy" with such a
> change.

I like this idea as a user - having made this change to p4merge, it does 
throw me when I decide to attempt a particularly tricky merge with bc3 
instead, and get the other order. The user config options you suggest 
sound good to me.

For completion on this idea, I'd suggest difftool.xxx.reverse, to allow 
the orientation for 0- and 1-revision diffs to be chosen - allow the 
implied working tree version to be on the left or right. That would 
allow "ours-theirs" order, which some would view as being more 
consistent with the "ours-base-theirs" default for mergetool.

Would it be going too far to also have "xxxtool.reverse" to choose the 
global default? Then the choice hierarchy would be "xxxtool.xxx.reverse 
if set" > "optional inbuilt tool preference" > "xxxtool.reverse if set" 
 > "false". So the user could request a global swap, except that they'd 
have to explicitly override any tools that have a preferred orientation.

My only reservation is that I assume it would be implemented by swapping 
what's passed in $LOCAL and $REMOTE. Which seems a bit icky: 
$LOCAL="a.REMOTE.1234.c". On the other hand, $LOCAL and $REMOTE are 
already not very meaningful names for difftool... Maybe we should change 
to using $LEFT and $RIGHT, acknowledging the existing difftool 
situation, and that the user can now swap merges too.

I'd be happy to prepare a fuller patch on this sort of basis.

Kevin