Re: Replacement for "merge non-conflicting"?

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

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:
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]