Re: Replacement for "merge non-conflicting"?

[Kai Willadsen <kai willadsen gmail com>]

On 5 October 2014 01:08, Bálint Réczey <balint balintreczey hu> wrote:
> 2014-10-04 2:50 GMT+02:00 Kai Willadsen <kai willadsen gmail com>:
> > On 4 October 2014 10:37, Kai Willadsen <kai willadsen gmail com> wrote:
> > > So to be completely clear, *nothing* has changed in Meld here. We take
> > > the files we're given by git.
> > >
> > > The default meld mergetool looks to see if we support --output, and if
> > > so it gives us LOCAL/BASE/REMOTE, with --output=MERGED. If we *don't*
> > > support --output, it gives us LOCAL/MERGED/REMOTE, which is what
> > > you're seeing.
> >
> > Turns out GLib has broken GApplication command line handling. You can
> > confirm this is the problem you're seeing by running `meld --help` and
> > seeing no Meld-specific help.
> >
> > I don't know when, how or whether I will be able to fix this. It's one
> > in the long, long line of things that have been broken by this
> > GTK/GLib release cycle.
> >
> > As a workaround, you can change the git mergetool helper to not check
> > for --output and just always assume that it's there.
> Thanks!
> Do you have a link to the GLib bug? I would report it against the
> Debian package with the possible workaround.

Sure:
  https://bugzilla.gnome.org/show_bug.cgi?id=737869

Fortunately, despite my earlier grumpiness, it looks like there's a
reasonable chance of getting this fixed in a stable 2.42 release,
which would be great.

As an aside, if you're running GTK+ 3.14, etc. can you confirm whether
Meld's diff highlighting works as normal? I'm seeing what I had
assumed was a regression with background colours for diff chunks not
being drawn, but if it's only me then I'll have to investigate
further.

cheers,
Kai