Re: Replacement for "merge non-conflicting"?




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?

Cheers,
Kai



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]