Re: Replacement for "merge non-conflicting"?

[Bálint Réczey <balint balintreczey hu>]

Hi Kai,

2014-10-03 8:25 GMT+02:00 Kai Willadsen <kai willadsen gmail com>:
> On Oct 3, 2014 4:22 PM, "Bálint Réczey" <balint balintreczey hu> wrote:
> > 2014-09-30 21:40 GMT+02:00 Mitchel Humpherys <mitch special gmail com>:
> > > On Thu, Sep 18 2014 at 01:32:25 PM, Kai Willadsen
> > > <kai willadsen gmail com> wrote:
> > > > On 16 September 2014 07:26, Mitchel Humpherys <mitch special gmail com>
> > > > wrote:
> > > > > Looks like a recent update removed the "Merge non-conflicting" item
> > > > > from
> > > > > meld's "Changed" menu.  I thought "Merge All" would be the equivalent
> > > > > option but it always seems to result in not doing "the right thing"
> > > > > like
> > > > > "merge non-conflicting" did.  Is there a replacement workflow for
> > > > > "Merge
> > > > > non-conflicting" followed by manually resolving the remaining
> > > > > conflicts?
> > > >
> > > > "Merge All" is just a rename of the menu item. It does exactly the
> > > > same action that "Merge non-conflicting" used to do, so if anything
> > > > has broken then either it was already like that, or the merging code
> > > > has changed. I don't *think* the merging code has changed much
> > > > recently, but I'd have to double check.
> > >
> > > Hmm, all I know is that I get a bunch of stuff merged to the "middle"
> > > buffer from what I would deem the "wrong side"...  In prior versions of
> > > meld it always seemed to do exactly what I expected and wanted it to do.
> > > I'm not sure when this changed but this is what I'm seeing with meld
> > > 3.12.0.
> > I noticed the change in 3.12.0, too, but unfortunately I have already
> > uploaded
> > 3.12.0 to Debian unstable and it has migrated to testing.
> > I use meld very often for back-porting changes from active Wireshark
> > branches
> > to old ones and meld 1.8.x did what I considered a minimal
> > back-porting preferring
> > changes from the left as I remember. Meld 3.12.0's Merge All started
> > preferring
> > changes from the right which may make sense in some scenarios but breaks
> > my
> > use case, too.
> >
> > I can provide real-life test cases if needed, but they are far from
> > minimal ones. :-)
>
> No, that's actually useful, thanks! One thing that did change was that we
> have a new preference for pane order that affects three pane mode. I can see
> that this may have had unintended consequences for the merging code.
>
> Could you please change your three way merge order preference and see if
> that fixes/works around the problem for you?
I just tested meld 1.8.6 and the first difference was that when merge was fired
running 'git mergetool' meld starts with the before-merge state and 'Merge All'
merges the files, while meld 3.12.0 starts with the files _after_ git
performed the merges.
Pressing 'Merge All' several times switches the preferred side (LOCAL/REMOTE)
which is cool in both versions but I preferred the way 1.8.6 operated
redoing the merge in meld.

Regarding the REMOTE/LOCAL ordering I think the defaults are OK.

Cheers,
Balint