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

From: Kevin Bracey <kevin@bracey.fi>
Date: Mar 7, 2013, 17:14 UTC
Message-ID: <5138CAFE.2010602@bracey.fi>
In-Reply-To: <7vd2vboepi.fsf@alter.siamese.dyndns.org>

On 07/03/2013 09:23, Junio C Hamano wrote:

Show 6 quoted lines

> 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).

Show 14 quoted lines

> 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