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

[Völker Ronny]

Angel Ezquerra wrote:
> On Thu, Mar 21, 2013 at 1:21 PM, Völker Ronny <ronny.voelker at elaxy.de>
> wrote:
> > Pierre-Yves David wrote:
> >> On Thu, Feb 21, 2013 at 02:04:43PM +0000, Völker Ronny wrote:
> >> > # HG changeset patch
> >> > # User Ronny Voelker <ronny.voelker at gmail.com> # Date 1361454565 -
> >> 3600
> >> > # Node ID 138968bb44d36a06393ecb82c74490914f7598bc
> >> > # Parent  4921b5c2aeed8a6bb0918503f7802508538f01e5
> >> > Fix meld.args in mergetools.rc: add -o $output
> >> >
> >> > Without this argument meld saves the result of a merge in $base.
> >> > This is a temporary file, which is ignored by Mercurial.
> >> > So the result of the merge is lost.
> >> >
> >> > diff -r 4921b5c2aeed -r 138968bb44d3 contrib/mergetools.hgrc
> >> > --- a/contrib/mergetools.hgrc   Sun Feb 17 14:34:53 2013 -0600
> >> > +++ b/contrib/mergetools.hgrc               Thu Feb 21 14:49:25 2013 +0100
> >> > @@ -25,7 +25,7 @@
> >> > gpyfm.gui=True
> >> >  meld.gui=True
> >> > -meld.args=--label='local' $local --label='base' $base --label='other'
> >> > $other
> >> > +meld.args=--label='local' $local --label='base' $base --label='other'
> >> > +$other -o $output
> >> > meld.diffargs=-a --label='$plabel1' $parent --label='$clabel'
> >> > $child tkdiff.args=$local $other -a $base -o $output
> >>
> >> What the status of this patch (and of the merge config in general) I
> >> could not find out from the thread.
> >>
> >> Merge is a critical operation in DVCS. It absolutly necessary that
> >> merge operation are clear to the end user. I seems like the "output"
> >> panel (where change will be kept) is unclear with the current
> >> configuration. Can we fix that?
> >>
> >>
> >>
> >> --
> >> Pierre-Yves David
> >>
> >> http://www.logilab.fr/
> >
> > There were three separate issues discussed in this Thread:
> >
> > 1. The current configuration for meld is not clear and orders the panels in a
> way, which is different to that what Meld (and other merge tools of the
> same kind) seems to prefer (merge from left and right into the center panel).
> > This is the sole issue my patch should solve, because with the current
> configuration I lost code changes after rebasing.
> > The panel names are copied from the configuration for Araxis Merge
> (which has the same merging model).
> > Still, one can argue that from the labeling of the panels it's not obvious
> which is the target panel.
> > Angel proposed to rename the center panel from 'base' to 'merged', which
> would be ok for me.
> >
> > 2. In the discussion was raised the issue, that meld isn't configured to
> automatically merge on startup.
> > The latest version of Meld has a command line option to merge on startup,
> but older versions are lacking that option.
> > As a workaround the Meld-dev proposed a configuration, where
> > mercurials automerge is used, with the drawback, that the information
> about the base version is lost.  I think the base version is valuable and we
> should go without automerge on startup for now.
> >  Manually triggering the automatic merging after startup is only one click
> away.
> >
> > 3. While skimming over the configuration of the other merge tools, I found
> that the naming of the panels is not consistent across merge tools with the
> same merging model.
> > E.g. for some the center panel is 'base', for some it is 'merged'.
> > I would expect that, when I use different merge tools of the same kind, the
> panels are named the same.
> > But this is too a minor issue for me.
> >
> >
> > Ronny
> 
> Personally I think that we should do #2, i.e. we should configure mercurial to
> do a pre-merge for us. I think it is weird to start a merge tool and have to
> manually do the merge. I expect the non conflicts to be solved for me, so
> that I can focus on the actual conflicts. Since the merge output will be at the
> center it will be easy to tell what changed from one revision to the other.
> 
> It would be nice to also have the base file, but if I had to choose between
> having the base or having the merge I'd rather have the merge.
> If I need both I can always use kdiff3.
> 
> Also, I think doing #1 (renaming 'base' to 'merge') without doing #2 (i.e.
> actually merging) would be confusing. The user may think that what he sees
> in the merge panel is the actual merge result, which would not be true.
> 
> Any other opinions?
> 
> Cheers,
> 
> Angel

I will go with Pierre-Yves advice: 
Expect the latest version of Meld and let the packager sort it out. 
That means, name the center panel 'merged', add --auto-merge, add a comment about the minimum required version of Meld and
add a commented out config for older versions, without --auto-merge and the center panel named 'target'.

What do you think?

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