Kevin Bracey [off-list ref] writes:
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).
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.
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.
How does that sound? David?
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