Henning Schild <henning.sch...@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.sch...@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
