git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
David Aguilar <davvid@gmail.com>
Date
Mar 7, 2013, 19:50 UTC
Message-ID
<CAJDDKr5-ttcU48r0-qTfov7q736Rj63rS33fTScSsvx53VG4pA@mail.gmail.com>
In-Reply-To
<7vboavm3fh.fsf@alter.siamese.dyndns.org>
On Thu, Mar 7, 2013 at 11:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 29 quoted lines
> Kevin Bracey <kevin@bracey.fi> writes:
>
>> 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).
>
> So in short, a user of p4merge can see that left side is intended as
> "theirs", even though recent p4merge sometimes calls it "left".  And
> your description on the coloring (green vs blue) makes it clear that
> "left" and "theirs" are still intended to be synonyms.
>
> If that is the case I would think you can still argue such a change
> as "correcting a 3-4-year old bug".

I would prefer to treat this as a bugfix rather than introducing a new set of configuration knobs if possible. It really does seem like a correction.

Users that want the traditional behavior can get that by configuring a custom mergetool.p4merge.cmd, so we're not completely losing the ability to get at the old behavior.

Users that want to see a reverse diff with difftool can already say "--reverse", so there's even less reason to have it there (though I know we're talking about mergetool only).

Show 6 quoted lines
>> Would it be going too far to also have "xxxtool.reverse" to choose the
>> global default?
>
> It would be a natural thing to do.  I left it out because I thought
> it would go without saying, given that precedences already exist,
> e.g. mergetool.keepBackup etc.
Medium NACK.  If we can do without configuration all the better.

I would much rather prefer to have the default/mainstream behavior be the best out-of-the-box sans configuration.

The reasoning behind swapping them for p4merge makes sense for p4merge only. I don't think we're quite ready to declare that all the merge tools need to be swapped or that we need a mechanism for swapping the order.

Show 23 quoted lines
>> 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".
>
> Doesn't the UI show the actual temporary filename?  When merging my
> version of hello.c with your version, showing them as hello.LOCAL.c
> and hello.REMOTE.c is an integral part of the UI experience, I
> think, even if the GUI tool does not give its own labels (and
> behaviour differences as you mentioned for p4merge) to mark which
> side is theirs and which side is ours.  The temporary file that
> holds their version should still be named with REMOTE, even when the
> mergetool.reverse option is in effect.
>
> As to the name of the variable, I do not care too deeply about it
> myself, but I think keeping the current LOCAL and REMOTE would help
> people following the code, especially given the option is called
> "reverse", meaning that there is an internal convention that the
> order is "LOCAL and then REMOTE".
>
> One thing to watch out for is from which temporary file we take the
> merged results.  You can present the two sides swapped, but if the
> tool always writes the results out by updating the second file, the
> caller needs to be prepared to read from the one that gets changed.
-- 
David
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 40 in “Improve P4Merge mergetool invocation”
  1. 0/2 Improve P4Merge mergetool invocationKevin Bracey, Mar 6, 2013
  2. 1/2 p4merge: swap LOCAL and REMOTE for mergetoolKevin Bracey, Mar 6, 2013
  3. Junio C HamanoMar 7, 2013
  4. Kevin BraceyMar 7, 2013
  5. Junio C HamanoMar 7, 2013
  6. Kevin BraceyMar 7, 2013
  7. Junio C HamanoMar 7, 2013
  8. David AguilarMar 7, 2013
  9. Junio C HamanoMar 7, 2013
  10. 2/2 p4merge: create a virtual base if none availableKevin Bracey, Mar 6, 2013
  11. David AguilarMar 7, 2013
  12. Kevin BraceyMar 7, 2013
  13. Junio C HamanoMar 7, 2013
  14. David AguilarMar 7, 2013
  15. 0/3 Improve P4Merge mergetool invocationKevin Bracey, Mar 9, 2013
  16. 1/3 mergetools/p4merge: swap LOCAL and REMOTEKevin Bracey, Mar 9, 2013
  17. 2/3 mergetools/p4merge: create a base if none availableKevin Bracey, Mar 9, 2013
  18. Junio C HamanoMar 10, 2013
  19. 3/3 git-merge-one-file: revise merge error reportingKevin Bracey, Mar 9, 2013
  20. 1/3 mergetools/p4merge: swap LOCAL and REMOTEKevin Bracey, Mar 13, 2013
  21. 2/3 mergetools/p4merge: create a base if none availableKevin Bracey, Mar 13, 2013
  22. 3/3 git-merge-one-file: revise merge error reportingKevin Bracey, Mar 13, 2013
  23. David AguilarMar 13, 2013
  24. 0/3 git-merge-one-file error reportingKevin Bracey, Mar 24, 2013
  25. 1/3 git-merge-one-file: style cleanupKevin Bracey, Mar 24, 2013
  26. 2/3 git-merge-one-file: send "ERROR:" messages to stderrKevin Bracey, Mar 24, 2013
  27. 3/3 git-merge-one-file: revise merge error reportingKevin Bracey, Mar 24, 2013
  28. Junio C HamanoMar 25, 2013
  29. Junio C HamanoMar 25, 2013
  30. Junio C HamanoMar 25, 2013
  31. Eric SunshineMar 25, 2013
  32. Junio C HamanoMar 13, 2013
  33. Kevin BraceyMar 14, 2013
  34. Junio C HamanoMar 14, 2013
  35. Kevin BraceyMar 14, 2013
  36. Kevin BraceyMar 14, 2013
  37. David AguilarMar 13, 2013
  38. 1/2 mergetools/p4merge: swap LOCAL and REMOTEKevin Bracey, Mar 24, 2013
  39. 2/2 mergetools/p4merge: create a base if none availableKevin Bracey, Mar 24, 2013
  40. Junio C HamanoMar 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.