Patchwork Fix meld.args in mergetools.rc: add -o $output

login
register
mail settings
Submitter Völker Ronny
Date March 28, 2013, 7:48 a.m.
Message ID <679C86927552B447B2A1522BFC65B7E32F30984F@srv-cob-vm-0059.elaxy.org>
Download mbox | patch
Permalink /patch/1203/
State Superseded
Commit 4085c9fafb8e6f1b68c8f9d4d549304d948e6e5a
Headers show

Comments

Völker Ronny - March 28, 2013, 7:48 a.m.
# HG changeset patch
# User ronvoe12249 <ronny.voelker@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).

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

Add --auto-merge, to enable automatic merging of all non-conflicting changes.
Angel Ezquerra - March 28, 2013, 4:05 p.m.
On Thu, Mar 28, 2013 at 8:48 AM, Völker Ronny <ronny.voelker@elaxy.de> wrote:
> # HG changeset patch
> # User ronvoe12249 <ronny.voelker@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).
>
> 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).
>
> Add --auto-merge, to enable automatic merging of all non-conflicting changes.
>
> diff -r fabbaa250977 -r 1873dc48d8ce contrib/mergetools.hgrc
> --- a/contrib/mergetools.hgrc   Sat Feb 09 21:51:21 2013 +0000
> +++ b/contrib/mergetools.hgrc   Thu Feb 21 14:49:25 2013 +0100
> @@ -25,7 +25,9 @@
>  gpyfm.gui=True
>
>  meld.gui=True
> -meld.args=--label='local' $local --label='base' $base --label='other' $other
> +meld.args=--label='local' $local --label='merged' $base --label='other' $other -o $output --auto-merge
> +;The option --auto-merge requires meld 1.7 or younger. For older versions use:
> +;meld.args=--label='local' $local --label='target' $base --label='other' $other -o $output
>  meld.diffargs=-a --label='$plabel1' $parent --label='$clabel' $child
>
>  tkdiff.args=$local $other -a $base -o $output

I just tried this with the latest version of meld on Windows (1.7). It
works better than what we had before.

That being said, for some reason I don't see the 'merge' label
anywhere. I see local on the left, other on the right but I see the
output filename on the center.

Also, TortoiseHg (and I guess mercurial would be the same) believes
that the merge was successful even if you do not save the output file.
I don't know if there is a way to fix that on the meld side? Otherwise
I think we should configure mercurial to ask the user if the merge was
successful when meld is closed if the file did not change:

meld.checkchanged=True

Another, final issue, is that it would be nice if the local / other
labels also indicated the revision number. I don't know if that is
possible.

Cheers,

Angel
Pierre-Yves David - March 28, 2013, 4:34 p.m.
On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
> Also, TortoiseHg (and I guess mercurial would be the same) believes
> that the merge was successful even if you do not save the output file.
> I don't know if there is a way to fix that on the meld side? Otherwise
> I think we should configure mercurial to ask the user if the merge was
> successful when meld is closed if the file did not change:
> 
> meld.checkchanged=True

That's a very serious issue
Angel Ezquerra - March 28, 2013, 4:41 p.m.
On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
<pierre-yves.david@logilab.fr> wrote:
> On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
>> Also, TortoiseHg (and I guess mercurial would be the same) believes
>> that the merge was successful even if you do not save the output file.
>> I don't know if there is a way to fix that on the meld side? Otherwise
>> I think we should configure mercurial to ask the user if the merge was
>> successful when meld is closed if the file did not change:
>>
>> meld.checkchanged=True
>
> That's a very serious issue

This is not something that has been introduced by this patch. This
problem already happened before (I just checked). Note that this may
be windows specific.

Volker's patch is an improvement over the current behavior. On windows
setting checkchanged to True would improve things, but then that would
not be necessary on linux. I don't know the best way to handled that.

Angel
Pierre-Yves David - March 28, 2013, 4:52 p.m.
On Thu, Mar 28, 2013 at 05:41:02PM +0100, Angel Ezquerra wrote:
> On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
> <pierre-yves.david@logilab.fr> wrote:
> > On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
> >> Also, TortoiseHg (and I guess mercurial would be the same) believes
> >> that the merge was successful even if you do not save the output file.
> >> I don't know if there is a way to fix that on the meld side? Otherwise
> >> I think we should configure mercurial to ask the user if the merge was
> >> successful when meld is closed if the file did not change:
> >>
> >> meld.checkchanged=True
> >
> > That's a very serious issue
> 
> This is not something that has been introduced by this patch. This
> problem already happened before (I just checked). Note that this may
> be windows specific.

I'm aware of that, just highlighting the seriousness of this issue on a general basis

> Volker's patch is an improvement over the current behavior. On windows
> setting checkchanged to True would improve things, but then that would
> not be necessary on linux. I don't know the best way to handled that.

This patch improves stuff that need to be improved too.

+1 for it
Angel Ezquerra - March 28, 2013, 7:14 p.m.
On Thu, Mar 28, 2013 at 5:52 PM, Pierre-Yves David
<pierre-yves.david@logilab.fr> wrote:
> On Thu, Mar 28, 2013 at 05:41:02PM +0100, Angel Ezquerra wrote:
>> On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
>> <pierre-yves.david@logilab.fr> wrote:
>> > On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
>> >> Also, TortoiseHg (and I guess mercurial would be the same) believes
>> >> that the merge was successful even if you do not save the output file.
>> >> I don't know if there is a way to fix that on the meld side? Otherwise
>> >> I think we should configure mercurial to ask the user if the merge was
>> >> successful when meld is closed if the file did not change:
>> >>
>> >> meld.checkchanged=True
>> >
>> > That's a very serious issue
>>
>> This is not something that has been introduced by this patch. This
>> problem already happened before (I just checked). Note that this may
>> be windows specific.
>
> I'm aware of that, just highlighting the seriousness of this issue on a general basis

What do you think is the best way to handle the different behavior
between Windows and the other platforms?

Angel
Pierre-Yves David - March 29, 2013, 9:52 a.m.
On Thu, Mar 28, 2013 at 08:14:31PM +0100, Angel Ezquerra wrote:
> On Thu, Mar 28, 2013 at 5:52 PM, Pierre-Yves David
> <pierre-yves.david@logilab.fr> wrote:
> > On Thu, Mar 28, 2013 at 05:41:02PM +0100, Angel Ezquerra wrote:
> >> On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
> >> <pierre-yves.david@logilab.fr> wrote:
> >> > On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
> >> >> Also, TortoiseHg (and I guess mercurial would be the same) believes
> >> >> that the merge was successful even if you do not save the output file.
> >> >> I don't know if there is a way to fix that on the meld side? Otherwise
> >> >> I think we should configure mercurial to ask the user if the merge was
> >> >> successful when meld is closed if the file did not change:
> >> >>
> >> >> meld.checkchanged=True
> >> >
> >> > That's a very serious issue
> >>
> >> This is not something that has been introduced by this patch. This
> >> problem already happened before (I just checked). Note that this may
> >> be windows specific.
> >
> > I'm aware of that, just highlighting the seriousness of this issue on a general basis
> 
> What do you think is the best way to handle the different behavior
> between Windows and the other platforms?

Wait, what ? You said that it *may* be windows specific did you confirmed it in the mean time?
I would assume that all plateform are affected.
Matt Mackall - April 1, 2013, 6:44 p.m.
On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
> # HG changeset patch
> # User ronvoe12249 <ronny.voelker@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. 

> diff -r fabbaa250977 -r 1873dc48d8ce contrib/mergetools.hgrc
> --- a/contrib/mergetools.hgrc	Sat Feb 09 21:51:21 2013 +0000
> +++ b/contrib/mergetools.hgrc	Thu Feb 21 14:49:25 2013 +0100
> @@ -25,7 +25,9 @@
>  gpyfm.gui=True
>  
>  meld.gui=True
> -meld.args=--label='local' $local --label='base' $base --label='other' $other
> +meld.args=--label='local' $local --label='merged' $base --label='other' $other -o $output --auto-merge
> +;The option --auto-merge requires meld 1.7 or younger. For older versions use:
> +;meld.args=--label='local' $local --label='target' $base --label='other' $other -o $output
>  meld.diffargs=-a --label='$plabel1' $parent --label='$clabel' $child
>  
>  tkdiff.args=$local $other -a $base -o $output
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Angel Ezquerra - April 1, 2013, 6:48 p.m.
On Mon, Apr 1, 2013 at 8:44 PM, Matt Mackall <mpm@selenic.com> wrote:
> On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
>> # HG changeset patch
>> # User ronvoe12249 <ronny.voelker@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?

Cheers,

Angel
Angel Ezquerra - April 1, 2013, 6:49 p.m.
On Fri, Mar 29, 2013 at 10:52 AM, Pierre-Yves David
<pierre-yves.david@logilab.fr> wrote:
> On Thu, Mar 28, 2013 at 08:14:31PM +0100, Angel Ezquerra wrote:
>> On Thu, Mar 28, 2013 at 5:52 PM, Pierre-Yves David
>> <pierre-yves.david@logilab.fr> wrote:
>> > On Thu, Mar 28, 2013 at 05:41:02PM +0100, Angel Ezquerra wrote:
>> >> On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
>> >> <pierre-yves.david@logilab.fr> wrote:
>> >> > On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
>> >> >> Also, TortoiseHg (and I guess mercurial would be the same) believes
>> >> >> that the merge was successful even if you do not save the output file.
>> >> >> I don't know if there is a way to fix that on the meld side? Otherwise
>> >> >> I think we should configure mercurial to ask the user if the merge was
>> >> >> successful when meld is closed if the file did not change:
>> >> >>
>> >> >> meld.checkchanged=True
>> >> >
>> >> > That's a very serious issue
>> >>
>> >> This is not something that has been introduced by this patch. This
>> >> problem already happened before (I just checked). Note that this may
>> >> be windows specific.
>> >
>> > I'm aware of that, just highlighting the seriousness of this issue on a general basis
>>
>> What do you think is the best way to handle the different behavior
>> between Windows and the other platforms?
>
> Wait, what ? You said that it *may* be windows specific did you confirmed it in the mean time?
> I would assume that all plateform are affected.

I did not test this, but I seem to recall from some messages on the
meld mailing list that this was a side effect of the way the windows
port is packaged.

Cheers,

Angel
Matt Mackall - April 1, 2013, 8:12 p.m.
On Mon, 2013-04-01 at 20:48 +0200, Angel Ezquerra wrote:
> On Mon, Apr 1, 2013 at 8:44 PM, Matt Mackall <mpm@selenic.com> wrote:
> > On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
> >> # HG changeset patch
> >> # User ronvoe12249 <ronny.voelker@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.

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.
Angel Ezquerra - April 2, 2013, 7:05 a.m.
On Mon, Apr 1, 2013 at 10:12 PM, Matt Mackall <mpm@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@selenic.com> wrote:
>> > On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
>> >> # HG changeset patch
>> >> # User ronvoe12249 <ronny.voelker@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
Völker Ronny - April 2, 2013, 7:05 a.m.
Angel Ezquerra wrote:
> On Mon, Apr 1, 2013 at 8:44 PM, Matt Mackall <mpm@selenic.com> wrote:
> > On Thu, 2013-03-28 at 07:48 +0000, Völker Ronny wrote:
> >> # HG changeset patch
> >> # User ronvoe12249 <ronny.voelker@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?
> 
> Cheers,
> 
> Angel

Premerge is enabled. I already wrote about this topic:
> Btw. while reading  http://mercurial.selenic.com/wiki/MergeToolConfiguration I found, that premerge is enabled by default, but won't help us with our problem.
> The option states,  that mercurial will try a merge on its own and only open the merge tool when it's encountering a conflict.
> When it encounters a conflict and opens the merge tool, then it serves all files unchanged. Non-conflicting changes are *not* automatically merged by mercurial.
> So at the end you have to merge everything manually.

Ronny
Pierre-Yves David - April 2, 2013, 8:43 a.m.
On Mon, Apr 01, 2013 at 01:44:28PM -0500, Matt Mackall wrote:
> > 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

Mercurial instalation process does not install this configuration file.
Packager explicitly includes them in their package. I would trust[1] the
RHEL/Centos packagers to read the release note and handle the situation
themself. Debian is already shipping a compatible meld version.
Matt Mackall - April 2, 2013, 10:57 p.m.
On Tue, 2013-04-02 at 10:43 +0200, Pierre-Yves David wrote:
> On Mon, Apr 01, 2013 at 01:44:28PM -0500, Matt Mackall wrote:
> > > 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
> 
> Mercurial instalation process does not install this configuration file.
> Packager explicitly includes them in their package. I would trust[1] the
> RHEL/Centos packagers to read the release note and handle the situation

Who are these packagers? They're not listed on our downloads page.

I'm not concerned about what >Redhat< does for RHEL. They package some
version of Mercurial so ancient that it isn't relevant to this
discussion.

I'm concerned about organizations/individuals that (sensibly) build
their own RPMs from our .spec files to backport recent Mercurial to
their systems. There are MANY of these; I now work for one. 

Communicating to all of them that they need to upgrade meld or need to
hack their scripts or revert our config change won't be easy. Having
them discover the hard way that they need to upgrade meld or change the
config is undesirable.

(It'd be AWESOME if there was someone publicly and regularly packaging
RHEL/Centos backports for the world, in which case I could reduce my
concern factor here.)
Angel Ezquerra - April 3, 2013, 9:36 p.m.
On Fri, Mar 29, 2013 at 10:52 AM, Pierre-Yves David
<pierre-yves.david@logilab.fr> wrote:
> On Thu, Mar 28, 2013 at 08:14:31PM +0100, Angel Ezquerra wrote:
>> On Thu, Mar 28, 2013 at 5:52 PM, Pierre-Yves David
>> <pierre-yves.david@logilab.fr> wrote:
>> > On Thu, Mar 28, 2013 at 05:41:02PM +0100, Angel Ezquerra wrote:
>> >> On Thu, Mar 28, 2013 at 5:34 PM, Pierre-Yves David
>> >> <pierre-yves.david@logilab.fr> wrote:
>> >> > On Thu, Mar 28, 2013 at 05:05:54PM +0100, Angel Ezquerra wrote:
>> >> >> Also, TortoiseHg (and I guess mercurial would be the same) believes
>> >> >> that the merge was successful even if you do not save the output file.
>> >> >> I don't know if there is a way to fix that on the meld side? Otherwise
>> >> >> I think we should configure mercurial to ask the user if the merge was
>> >> >> successful when meld is closed if the file did not change:
>> >> >>
>> >> >> meld.checkchanged=True
>> >> >
>> >> > That's a very serious issue
>> >>
>> >> This is not something that has been introduced by this patch. This
>> >> problem already happened before (I just checked). Note that this may
>> >> be windows specific.
>> >
>> > I'm aware of that, just highlighting the seriousness of this issue on a general basis
>>
>> What do you think is the best way to handle the different behavior
>> between Windows and the other platforms?
>
> Wait, what ? You said that it *may* be windows specific did you confirmed it in the mean time?
> I would assume that all plateform are affected.
>
> --
> Pierre-Yves David

Actually it turns out that I was wrong. This is _not_ windows
specific. Apparently meld does never change its exit code (it is
always zero). I'm trying to convince the meld dev that the correct
behavior is to return 0 only if the output panel was saved, but for
now I believe that we really need to set the checkchanged setting to
True.

Cheers,

Angel
Nikolaj Sjujskij - April 8, 2013, 10:44 a.m.
Den 2013-04-03 02:57:04 skrev Matt Mackall <mpm@selenic.com>:

> On Tue, 2013-04-02 at 10:43 +0200, Pierre-Yves David wrote:
>> On Mon, Apr 01, 2013 at 01:44:28PM -0500, Matt Mackall wrote:
>> > > 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
>>
>> Mercurial instalation process does not install this configuration file.
>> Packager explicitly includes them in their package. I would trust[1] the
>> RHEL/Centos packagers to read the release note and handle the situation
>
> Who are these packagers? They're not listed on our downloads page.
>
> I'm not concerned about what >Redhat< does for RHEL. They package some
> version of Mercurial so ancient that it isn't relevant to this
> discussion.
>
> I'm concerned about organizations/individuals that (sensibly) build
> their own RPMs from our .spec files to backport recent Mercurial to
> their systems. There are MANY of these; I now work for one.
  Could .spec-file contain Meld version restriction? So repackager would  
get an error if his Meld package version is too old. I'm not familiar with  
RPM-based systems, so it's just a suggestion.

> Communicating to all of them that they need to upgrade meld or need to
> hack their scripts or revert our config change won't be easy. Having
> them discover the hard way that they need to upgrade meld or change the
> config is undesirable.
>
> (It'd be AWESOME if there was someone publicly and regularly packaging
> RHEL/Centos backports for the world, in which case I could reduce my
> concern factor here.)

Patch

diff -r fabbaa250977 -r 1873dc48d8ce contrib/mergetools.hgrc
--- a/contrib/mergetools.hgrc	Sat Feb 09 21:51:21 2013 +0000
+++ b/contrib/mergetools.hgrc	Thu Feb 21 14:49:25 2013 +0100
@@ -25,7 +25,9 @@ 
 gpyfm.gui=True
 
 meld.gui=True
-meld.args=--label='local' $local --label='base' $base --label='other' $other
+meld.args=--label='local' $local --label='merged' $base --label='other' $other -o $output --auto-merge
+;The option --auto-merge requires meld 1.7 or younger. For older versions use:
+;meld.args=--label='local' $local --label='target' $base --label='other' $other -o $output
 meld.diffargs=-a --label='$plabel1' $parent --label='$clabel' $child
 
 tkdiff.args=$local $other -a $base -o $output