On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey <ke...@bracey.fi> 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.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to