On Tue, Sep 30 2014 at 02:14:30 PM, Kai Willadsen <[email protected]>
wrote:
> 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.
Ah interesting. I just just use `meld' as my mergetool:
$ git config -l | grep merge
merge.tool=meld
I've used it this way for several years. I believe this regression (if
it is indeed a regression and not some boneheaded config on my end)
happened sometime in this timeframe:
[2014-07-31 10:43] [PACMAN] upgraded meld (1.8.5-1 -> 3.11.2-2)
[2014-08-18 11:08] [PACMAN] upgraded meld (3.11.2-2 -> 3.11.2-3)
[2014-09-09 10:19] [PACMAN] upgraded meld (3.11.2-3 -> 3.11.3-1)
[2014-09-29 14:48] [PACMAN] upgraded meld (3.11.3-1 -> 3.12.0-1)
--
Mitch
_______________________________________________
meld-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/meld-list
