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. :-) Cheers, Balint > >> >> If you have a sample bad merge, please feel free to file a bug. > > Here's an example using git with meld as the mergetool: > > $ mkdir /tmp/melddemo; cd /tmp/melddemo > $ git init > $ seq 10 > test > $ git add test > $ git commit -m init > $ git checkout -b change1 > $ sed s/5/pizza/ -i test > $ git commit -am pizza > $ git checkout master > $ sed s/5/feast/ -i test > $ sed s/1/one/ -i test > $ git commit -am one > $ git merge change1 > $ git mergetool # use "Merge All" here > $ git diff --cached > > Here's how the final `git diff --cached' looks: > > $ git diff --cached > diff --git a/test b/test > index e6a96e7447..8411a685ce 100644 > --- a/test > +++ b/test > @@ -1,10 +1,10 @@ > -one > +1 > 2 > 3 > 4 > -feast > +pizza > 6 > 7 > 8 > 9 > -one0 > +10 > > As you can see, my `one's got reverted back to `1's even though the > stuff being merged in (change1 branch) didn't touch those lines at all. > In prior versions of meld only the conflicting stuff would have changed > and the `one's would have been left alone. > > Maybe this is specific to using meld as a git mergetool (which I would > imagine is a very common use case for meld)? > > > -- > Mitch > _______________________________________________ > meld-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/meld-list _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
