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

[Völker Ronny]

Angel Ezquerra wrote:
> 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

1. Premerge:
As I already said in other mails, Premerge *is* already enabled, but will not help us with the missing --auto-merge option (at least as I understand it).


2. One patch per issue:
I'm all for this approach. I will split up my patch.


3. Add -o $output:
First patch. This is the most important patch (for me, because it solves my original problem). 


3. Rename the center panel to 'target':
Second patch.


4. check=changed:
Third patch.
Good idea, Angel.


5. --auto--merge:
Different issue. Maybe another patch, if we agree on it.
It will break backward compatibility with older versions of Meld. There is no simple workaround for it.  
Premerge doesn't help.  
Two active configurations for Meld (one for >= 1.7 and one for <1.7) won't work, because both are referencing the same binary.
Alternative for older Meld:
Configuration as proposed by the meld dev, but with premerge=keep.
This will keep the conflict markers in the target file.
The advantage is, that the conflict markers somewhat preserve the base-information.
The disadvantage is, that the conflict markers are ugly.


6.  Add revision names to panel titles.
In http://mercurial.selenic.com/wiki/MergeToolConfiguration and hg help config  is nothing mentioned to accomplish this.


Ronny