[PATCH] Fix meld.args in mergetools.rc: add -o $output

[Angel Ezquerra]

On Mon, Apr 1, 2013 at 10:12 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2013-04-01 at 20:48 +0200, Angel Ezquerra wrote:
>> On Mon, Apr 1, 2013 at 8:44 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
>> >> # HG changeset patch
>> >> # User ronvoe12249 <ronny.voelker at elaxy.com>
>> >> # Date 1361454565 -3600
>> >> # Node ID 1873dc48d8ce764436f9b4904dd3c29d2f7ff90a
>> >> # Parent  fabbaa250977ad337a36b1c4cece22da94adfe4b
>> >> mergetools.hgrc meld.args: avoid loosing the merged version
>> >>
>> >> Rename the center panel to 'merged', to make it clear that this panel will contain
>> >> the merged version (as it is intended by Meld).
>> >
>> > Seems like a good idea.
>> >
>> >> Add -o $output, to avoid loosing the merged version.
>> >> With the previous configuration, the merged version was written to the wrong
>> >> file ($base, a temporary file, which is ignored by Mercurial).
>> >
>> > Seems like a good idea for another patch. One idea per patch, please.
>> > This one ought to be on the stable branch, as it's fixing a bug?
>> >
>> >> Add --auto-merge, to enable automatic merging of all non-conflicting changes.
>> >
>> > Questionable. How long has the current release been out? If people
>> > install this on their gnarly old RHEL system, are they going to need to
>> > hack their config to work with their gnarly old meld? My guess is yes
>> >
>> > Save until the first two get dealt with, please.
>>
>> What will be the best way to deal with this? Perhaps add a new meld17 config?
>>
>> Also, what do you think of enabling premerge for meld?
>
> First, I'd like folks to recognize that we have a real problem with
> derailing new submitters by bringing up related issues like this. They
> (quite naturally) think that they should try to roll such things into
> their patch. And of course, that's exactly the opposite of what we want
> them to do.

You are right. It was not my intention to derail Volker's submission,
particularly now that we agree on what must be done.

> I think all merge tools should pre-merge by default. But it's not clear
> how we can do that in meld without breaking things.
>
> So, again, let's save this until the first couple issues get dealt with,
> please.

OK, this is definitely a separate issue of the one that Volker wants
to address. As you say it should be dealt after Volker resends his
patch (split in two).

That being said, I don't quite understand why you say that enabling
premerge in meld by default would break things. FYI, this is what Kai
Willadsen (meld's main dev) said to me on the meld mailing list when
discussing this a while ago:

"I personally prefer (in Mercurial terms, so the details may be wrong)
$local $output $base with premerge = True. This loses the ancestor
information though, so until we add diff3 support for pruning that
out, I can't really say that it's an
obvious win."

So his suggestion is to use premerge = True as well.

Perhaps you were referring to the use of the no backwards compatible
--auto-merge flag?

Angel