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

[Angel Ezquerra]

On Wed, Mar 27, 2013 at 9:56 AM, Völker Ronny <ronny.voelker at elaxy.de> wrote:
> 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
>

OK, I agree with you then. Maybe name the old version meld16 for
example, and the new one just meld.

Maybe in the case of the merge16 config the center panel could be
named "target (not merged)" or "target (base)" or something similar to
indicate that _no merge_  happened?

Also, perhaps we should use premerge in all cases?

Cheers,

Angel