Re: [PATCH 2/6] t5334: document that git push --signed=1 does not work

Martin Ågren [off-list ref] writes:

When accepting booleans as command-line or config options throughout
Git, there are several documented synonyms for true and false.
However, one particular user is slightly broken: `git push --signed=..`
does not understand the integer synonyms for true and false.

This is hardly wanted. The --signed option has a different notion of
boolean than all other arguments and config options, including the
config option corresponding to it, push.gpgSign.

Add a test documenting the failure to handle --signed=1.

My knee-jerk reaction is that parse_maybe_bool() is broken in that
it should do everything that config_maybe_bool() does.  I wonder why
we do not call git_parse_int() like git_config_maybe_bool() does?

... Ahh, that is because bool_or_int() wants to know that "1" is an
int and not a bool, and parse_maybe_bool() is designed to cater to
the need of that thing, in addition to config_maybe_bool().  And the
"--signed=" thing wants parse_bool_or_string(), not bool_or_int(),
so we should treat "1" as true and "0" as false.  There is no way to
do so in the current code and that is why you have the new _text()
thing in patches 3-4/6.

Makes sense.

n> +	mkdir -p dst/.git/hooks &&

+	test_must_fail git push --signed=1 dst noop ff +noff 2>err &&
+	test_i18ngrep "the receiving end does not support" err
+'
+
 test_expect_success GPG 'no certificate for a signed push with no update' '
 	prepare_dst &&
 	mkdir -p dst/.git/hooks &&