Re: A note on modern git plus ancient meld ("wrong number of arguments")

Jonathan Nieder [off-list ref] writes:

Just parse version numbers instead.  We can detect the version number
by running "meld --version" and postprocessing it.

Hmm. I am debating myself if it may be more efficient, less error prone
and simpler for the users if we gave them "mergetool.meld.useOutput"
configuration option to tweak.

When an older meld fails when given --output for real (not with the dry
run current code tries with --help), can we sanely detect that particular
failure?  If we can do so, another possibility may be to do something like
this:

merge_cmd () {
	meld_has_output_option=$(git config --bool mergetool.meld.useOutput)
	case "$meld_has_output_option" in
        false)
		... do the non-output thing ...
		;;
	true)
		"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
		;;
	*)
		"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
		if it failed due to missing --output support?
		then
			meld_has_output_option=no
                        git config mergetool.meld.useOutput false
			merge_cmd
		fi
                ;;
	esac
}

In v1.7.7-rc0~3^2 (2011-08-19), git mergetool's "meld" support learned
to use the --output option when calling versions of meld that are
detected to support it (1.5.0 and newer, hopefully).

Alas, it misdetects old versions (before 1.1.5, 2006-06-11) of meld as
supporting the option, so on systems with such meld, instead of
getting a nice merge helper, the operator gets a dialog box with the
text "Wrong number of arguments (Got 5)".  (Version 1.1.5 is when meld
switched to using optparse.  One consequence of that change was that
errors in usage are detected and signalled through the exit status
even when --help was passed.)

Luckily there is a simpler check that is more reliable: the usage
string printed by "meld --help" reliably reflects whether --output is
supported in a given version.  Use it.

Reported-by: Jeff Epler <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
Junio C Hamano wrote:

When an older meld fails when given --output for real (not with the dry
run current code tries with --help), can we sanely detect that particular
failure?

Unfortunately it just pops up a GUI with a modal dialog box like this:
	 ___________________________________
	|                                   |
	| Wrong number of arguments (Got 5) |
	|                                   |
	|                     [Quit] [OK]   |
	|___________________________________|

If I choose "Quit", the exit status is 0.

But how about this?  "meld --help | grep -e --output" seems to detect
support for the option reliably.  With 2>&1 on the upstream of the
pipe, this even seems futureproof. ;-)

 mergetools/meld |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mergetools/meld b/mergetools/meld
index eaa115cc..cb672a55 100644
--- a/mergetools/meld
+++ b/mergetools/meld

@@ -23,7 +23,7 @@ check_meld_for_output_version () {
 	meld_path="$(git config mergetool.meld.path)"
 	meld_path="${meld_path:-meld}"
 
-	if "$meld_path" --output /dev/null --help >/dev/null 2>&1
+	if "$meld_path" --help 2>&1 | grep -e --output >/dev/null
 	then
 		meld_has_output_option=true
 	else

-- 
1.7.9

I appreciate the interest you've all taken in my report, but I really
don't think there's any need to do anything about this "problem" besides
let people find this thread, in which they can learn to try upgrading
their meld to one that's only 5 1/2 years old.

That said, another possibility is to test whether
    meld --commandline-option-that-cannot-possibly-exist --help
exits with status 0; if it does, then exit-status based probing of
meld's capabilities won't work.  In this case, assume --output is not
available.

Jeff

On Fri, Feb 10, 2012 at 03:57:55PM -0600, Jonathan Nieder wrote:

I can confirm that this iteration of the patch (meld --help | grep)
worked for me on meld 1.1.1, meld 1.1.5, and meld 1.3.0.  Note however
that none of these are versions of meld that do support the --output
flag.

Tested-by: Jeff Epler <redacted>

Jeff