On 3 October 2014 18:16, Bálint Réczey <[email protected]> wrote: > 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.
So to be completely clear, *nothing* has changed in Meld here. We take the files we're given by git. The default meld mergetool looks to see if we support --output, and if so it gives us LOCAL/BASE/REMOTE, with --output=MERGED. If we *don't* support --output, it gives us LOCAL/MERGED/REMOTE, which is what you're seeing. cheers, Kai _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
