Martin Ågren <martin.agren@xxxxxxxxx> 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. > diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh > index 464ffdd14..5dce55e1d 100755 > --- a/t/t5534-push-signed.sh > +++ b/t/t5534-push-signed.sh > @@ -71,6 +71,13 @@ test_expect_success 'push --signed fails with a receiver without push certificat > test_i18ngrep "the receiving end does not support" err > ' > > +test_expect_failure 'push --signed=1 is accepted' ' > + prepare_dst && 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 &&
