Re: [PATCH 5/8] t/t7510: check the validation of the new config gpg.format

[Junio C Hamano <gitster@pobox.com>]

Henning Schild <henning.schild@siemens.com> writes:

> Valid values are already covered by all tests that use GPG, now also
> test what happens if we go for an invalid one.
>
> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
>  t/t7510-signed-commit.sh | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index 6e2015ed9..cb523513f 100755
> --- a/t/t7510-signed-commit.sh
> +++ b/t/t7510-signed-commit.sh
> @@ -227,4 +227,14 @@ test_expect_success GPG 'log.showsignature behaves like --show-signature' '
>  	grep "gpg: Good signature" actual
>  '
>  
> +test_expect_success GPG 'check gpg config for malformed values' '
> +	mv .git/config .git/config.old &&
> +	test_when_finished "mv .git/config.old .git/config" &&

Hmmmmm.  

Is the damage caused by throwing a bad value at gpg.format designed
to be so severe that "test_when_finished test_unconfig ..." cannot
recover from?  This test script is not about how "git config" is
implemented and works, so it would be a good idea for it to be even
oblivious to the fact that .git/config is the file being mucked with
when we do "git config".

I have a suspicion that you can just use test_config (which would
arrange "test_when_finished test_unconfig ..." for free).

> +	git config gpg.format malformed &&
> +	test_expect_code 128 git commit -S --amend -m "fail" 2>result &&

Is this 128 something we document and have users rely on?  Or should
we rather say

	test_must_fail git commit ...

here instead?

> +	test_i18ngrep "malformed value for gpg.format: malformed" result &&
> +	test_i18ngrep "fatal: .*\.git/config" result &&
> +	test_i18ngrep "fatal: .*line 2" result
> +'
> +
>  test_done