Hi Kai, 2014-10-03 8:25 GMT+02:00 Kai Willadsen <[email protected]>: > > On Oct 3, 2014 4:22 PM, "Bálint Réczey" <[email protected]> wrote: >> >> 2014-09-30 21:40 GMT+02:00 Mitchel Humpherys <[email protected]>: >> > On Thu, Sep 18 2014 at 01:32:25 PM, Kai Willadsen >> > <[email protected]> wrote: >> >> On 16 September 2014 07:26, Mitchel Humpherys <[email protected]> >> >> 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 _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
