Regressions in 0.9.98 make KDiff3 unusable. Upstream bug: https://bugs.kde.org/show_bug.cgi?id=346154
Thanks for the report and opening the upstream bug! 0.9.97-r2 is now back in tree I wonder if this is kdiff3 itself or a qt bug though (I have not seen this with 0.9.98, but I have a qt5 build)
Well, I used the same Qt with both versions, so unless 0.9.98 removed a workaround it suggests a KDiff3 bug IMO.
This is an issue again... kensington removed it. :( Why was kdiff3 0.9.98-r1 stabilised at all with this very serious known bug?
Please check the git log again, I dropped 0.9.98-r0, not 0.9.97-r2. I have restored the dropped version again, am converting this bug into something to track the regression, and dropping KDE project as a maintainer.
I've added KF5-based snapshot kde-misc/kdiff3-0.9.98_p20170219 to tree, please test.
The qt5 snapshots appears to have dropped a number of command line options and as a result git becomes unusable with kdiff3 as merge tool. Specifically, git kdiff3 mergetool makes use of the --L1, --L2 and --L3 command line options to provide labels for the files.
Here is more of a clue when running kde-misc/kdiff3-0.9.98_p20170219 (the KF5 snapshot): $ kdiff3 QCommandLineParser: option not defined: "confighelp" QCommandLineParser: option not defined: "cs" QCommandLineParser: option not defined: "qall" QCommandLineParser: option not defined: "fname" QCommandLineParser: option not defined: "L1" QCommandLineParser: option not defined: "L2" QCommandLineParser: option not defined: "L3"
Created attachment 472306 [details, diff] Implements missing command line options The attached patch fixes the missing command line options issue and allows kdiff3 to be used as git mergetool again.
Thanks peteru, I've forwared the patch to upstream. @Luke-Jr, has this ever been about kdiff3[qt5] and if so, is your initial bug fixed by the 0.9.98_p20170219 snapshot?
(In reply to Andreas Sturmlechner from comment #9) > Thanks peteru, I've forwared the patch to upstream. > > @Luke-Jr, has this ever been about kdiff3[qt5] and if so, is your initial > bug fixed by the 0.9.98_p20170219 snapshot? I only ever encountered the issue using git-mergetool, so if it doesn't work with the snapshot, I have no way to test. I suppose I could use peteru's patch to try it out if that'd be helpful?
It is already in tree with -r1 if you want to give it a try, tia.
I am unable to reproduce the original problem with either 0.9.98-r1 or 0.9.98_p20170219-r1. When I originally opened this bug, I was running x86[_32]. I am now running amd64. Unsure if this is related...
It seems here as well as upstream no one else has seen that bug. Should we close it?
(In reply to Andreas Sturmlechner from comment #13) > It seems here as well as upstream no one else has seen that bug. Should we > close it? Up to you. If someone feels motivated, they might try to install a 32-bit chroot and see if it can be reproduced, but I'm not sure anyone really cares about 32-bit anymore. FWIW, the relevant bits of my .gitconfig: [alias] kdiff = difftool --dir-diff --no-symlinks [diff] tool = kdiff3 ignoreSubmodules = untracked [mergetool "kdiff3"] trustExitCode = false
(In reply to Luke-Jr from comment #14) > (In reply to Andreas Sturmlechner from comment #13) > > It seems here as well as upstream no one else has seen that bug. Should we > > close it? > > Up to you. Done.