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

Angel Ezquerra angel.ezquerra at gmail.com
Thu Mar 21 08:05:23 CDT 2013


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


More information about the Mercurial-devel mailing list