On 1 October 2014 05:40, Mitchel Humpherys <[email protected]> wrote: > 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. > >> >> 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: <snip> > 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.
Thanks for the test case. I'll try and take a proper look when I get some time. However... (below) > Maybe this is specific to using meld as a git mergetool (which I would > imagine is a very common use case for meld)? Yes, definitely. > Some other evidence that the merge code has changed within the past few > months (at least on my distro (Arch Linux)) is that it now leaves git's > merge markers in the output buffer, which I don't remember it ever doing > before. I'm fine with that change, btw, but there seem to be some other > side-effects with recent merge code changes... This definitely shouldn't happen, and suggests to me that either your git mergetool setup has changed, or Meld has changed the way we parsed your existing git mergetool command. If there are git merge markers in your output then it means that we're getting a pre-merged file from git as an input, and that definitely won't work. For merging to Do The Right Thing, it needs to get left/ancestor/right. If it has left/premerged/right then I'd expect stuff to break. Do you have a custom mergetool configured? (git config -l | grep mergetool) The upstream meld mergetool was last changed about three years ago, so I doubt that's the problem. We *may* have broken something in our command line parsing however. cheers, Kai _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
