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