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

From: Kevin Bracey <[email-masked]>
Date: Thu, 07 Mar 2013 08:16:13 +0200

On 07/03/2013 02:36, Junio C Hamano wrote:
> Kevin Bracey <[email-masked]> writes:
>
>> Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
>> the incoming branch is now in the left-hand, blue triangle pane, and the
>> current branch is in the right-hand, green circle pane.
> Given that the ordering of the three variants has been the way it is
> since the very initial version by Scott, I'll sit on this patch
> until hearing from those Cc'ed (who presumably do use p4merge,
> unlike I who don't) that it is a good change.
>
I agree that this is the controversial patch of the two. It's going to 
chuck away 3-4 years of what Git users are used to, albeit in favour of 
a decade of what Perforce users are used to. And it also makes it 
inconsistent with all the other mergetools (at least assuming their 
display matches their command line).

I checked for any historical discussion from when this was added about 
the order, and there was none. So I'm assuming it was just done to match 
the other tools, maybe not realising P4Merge's "theirs/ours" convention. 
There was no explicit recognition at the time that they were breaking 
the Perforce convention, or that the order had an effect.

I've used both Git and Perforce for quite a while, but have only just 
started using P4Merge with Git. It seemed weirdly off and unintuitive to 
me at first, until I suddenly realised that it was just backwards.  I 
would have settled for just having to get used to driving on the other 
side of the road, and matching other mergetools, until I realised that 
it effectively broke display of common changes. That's a problem.

On consistency, personally, I think there's an argument for reversing 
all the mergetools to match this way, as I find this orientation more 
intuitively aligns with difftool. But I'm not bold enough to suggest 
that. Yet.

Kevin