t1401: test symbolic-ref exit codes on a non-symbolic ref - #2204
t1401: test symbolic-ref exit codes on a non-symbolic ref#2204nikolauspschuetz wants to merge 1 commit into
Conversation
|
/submit |
|
Submitted as pull.2204.git.1786655554197.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
345e664 to
fa9dd1d
Compare
|
This branch is now known as |
|
This patch series was integrated into seen via git@799dea8. |
|
There was a status update in the "New Topics" section about the branch A few additional tests. Needs review. source: <pull.2204.git.1786655554197.gitgitgadget@gmail.com> source: <pull.2203.git.1786653837190.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A few additional tests. Needs review. source: <pull.2204.git.1786655554197.gitgitgadget@gmail.com> source: <pull.2203.git.1786653837190.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch A few additional tests. Needs review. source: <pull.2204.git.1786655554197.gitgitgadget@gmail.com> source: <pull.2203.git.1786653837190.gitgitgadget@gmail.com> |
|
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email): On Thu, Aug 13, 2026 at 09:12:33PM +0000, Nikolaus Schuetz via GitGitGadget wrote:
> From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
>
> git-symbolic-ref(1) documents that reading a name that is not a
> symbolic ref exits with a non-zero status, and that --quiet does so
> silently rather than printing a diagnostic. This was not tested.
Out of curiosity, what made you address these gaps in particular? Is
there any motivation, or are you just picking random things to work on?
> Check that querying a non-symbolic ref exits 128 with the usual
> "is not a symbolic ref" message, and that --quiet instead exits 1
> with no output.
This is testing the status quo, but what I think would be good to
research in this context is why the error codes are different in the
first place. I personally find that quite a bit puzzling, as my
expectation would be that "--quiet" really only impacts whether we print
anything or not. That it also changes the error code is weird.
> diff --git a/t/t1401-symbolic-ref.sh b/t/t1401-symbolic-ref.sh
> index a2a7e94716..602db6d080 100755
> --- a/t/t1401-symbolic-ref.sh
> +++ b/t/t1401-symbolic-ref.sh
> @@ -38,6 +38,16 @@ test_expect_success 'symbolic-ref refuses bare sha1' '
>
> reset_to_sane
>
> +test_expect_success 'symbolic-ref reports a non-symbolic ref with exit code 128' '
> + test_expect_code 128 git symbolic-ref refs/heads/foo 2>err &&
> + test_grep "is not a symbolic ref" err
> +'
> +
> +test_expect_success 'symbolic-ref -q is silent and exits 1 on a non-symbolic ref' '
> + test_expect_code 1 git symbolic-ref -q refs/heads/foo 2>err &&
> + test_must_be_empty err
> +'
Do we also want to verify that stdout is empty in both cases?
Thanks!
Patrick |
|
User |
git-symbolic-ref(1) documents that reading a name that is not a symbolic ref exits non-zero, and that --quiet does so silently. Tests such as t2020 and t5621 already rely on "symbolic-ref -q HEAD" failing on a detached HEAD, but none pins the exact exit codes or checks that --quiet actually suppresses the diagnostic. Assert that a non-symbolic ref exits 128 with the "is not a symbolic ref" message, and that --quiet instead exits 1 with no output. Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
fa9dd1d to
22694da
Compare
|
Nikolaus Schuetz wrote on the Git mailing list (how to reply to this email): > Out of curiosity, what made you address these gaps in particular? Is
> there any motivation, or are you just picking random things to work on?
Not random -- I've been going through git commands, checking whether the
behavior their man pages promise is actually exercised from t/, and
filling the gaps. The idea is to pin the documented contract in a test so
a later refactor can't quietly change it. git-symbolic-ref(1) spells out
both the exit status and the --quiet silence, but neither was tested, so
they stood out.
> This is testing the status quo, but what I think would be good to
> research in this context is why the error codes are different in the
> first place.
Agreed it's surprising, though it's not unique to symbolic-ref: git
rev-parse --verify --quiet does the same thing (exit 1 and silent, vs a
fatal 128 without --quiet). It falls out of how the two paths report in
check_symref() (builtin/symbolic-ref.c): the non-quiet path calls die(),
which always exits 128, while --quiet can't die() -- that would print --
so it returns 1.
> Do we also want to verify that stdout is empty in both cases?
Great idea. I've revised the added tests to redirect stdout and check
for empty stdout in both cases.
Thanks,
Nikolaus |
|
/submit |
|
Submitted as pull.2204.v2.git.1787264402361.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
There was a status update in the "Cooking" section about the branch A few additional tests. Expecting a reroll. cf. <20260820151325.58087-1-nikolauspschuetz@gmail.com> cf. <20260820144648.47267-1-nikolauspschuetz@gmail.com> source: <pull.2204.git.1786655554197.gitgitgadget@gmail.com> source: <pull.2203.git.1786653837190.gitgitgadget@gmail.com> |
git-symbolic-ref(1) documents that reading a name that is not a symbolic ref exits with a non-zero status, and that --quiet does so silently rather than printing a diagnostic. This exit-code contract was untested.
This adds two tests: querying a non-symbolic ref exits 128 with the usual "is not a symbolic ref" message, and --quiet instead exits 1 with no output.
Test-only; documents existing behaviour, in the spirit of 919eb8a (t1402: check for refs ending with a dot).
cc: Patrick Steinhardt ps@pks.im