Re: Replacement for "merge non-conflicting"?

[Kai Willadsen <kai willadsen gmail com>]

On 1 October 2014 05:40, Mitchel Humpherys <mitch special gmail com> wrote:
> 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.
>
> > 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