On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey <kevin@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html