From: Patrick Steinhardt <ps@pks.im>
To: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] t3200: replace hardcoded null OID with $ZERO_OID
Date: Wed, 11 Mar 2026 12:20:22 +0100 [thread overview]
Message-ID: <abFP9vZOVHGI536G@pks.im> (raw)
In-Reply-To: <20260311105829.60508-1-r.siddharth.shrimali@gmail.com>
On Wed, Mar 11, 2026 at 04:28:10PM +0530, Siddharth Shrimali wrote:
> Taking into consideration the SHA-256 transition, the test suite must
> be updated to support the length of the underlying hash algorithm.
> Tests that rely on hardcoded 40-character strings to represent the
> null object ID will fail when run in a SHA-256 environment, which
> expects a 64-character hash.
>
> Replace the hardcoded 40-zero string in the 'git branch --merged' test
> with the '$ZERO_OID' variable which is provided by the test framework.
> This ensures the test dynamically adapts to the correct null OID
> length and functions correctly regardless of the active hash
> algorithm.
>
> Signed-off-by: Siddharth Shrimali <r.siddharth.shrimali@gmail.com>
> ---
> t/t3200-branch.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> index c58e505c43..ed317a75f5 100755
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -1494,7 +1494,7 @@ test_expect_success 'refuse --edit-description on unborn branch for now' '
> '
>
> test_expect_success '--merged catches invalid object names' '
> - test_must_fail git branch --merged 0000000000000000000000000000000000000000
> + test_must_fail git branch --merged $ZERO_OID
> '
I expect that the failure reason before and after this change is
different, right? And likewise, I expect that before the change, the
failure with SHA1 is likely different than the one with SHA256.
Taking a peek, that's indeed the case. With SHA1 we get:
error: option `merged' must point to a commit
But with SHA256 we get:
fatal: malformed object name 0000000000000000000000000000000000000000
So the only reason why we didn't detect that the test is broken with
SHA256 is that we didn't verify the error message. Do we maybe want to
make the test a bit less fragile by using something like `test_grep
"must point to a commit"` on the error message?
Patrick
next prev parent reply other threads:[~2026-03-11 11:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 10:58 [PATCH] t3200: replace hardcoded null OID with $ZERO_OID Siddharth Shrimali
2026-03-11 11:20 ` Patrick Steinhardt [this message]
2026-03-11 17:41 ` [PATCH v2] " Siddharth Shrimali
2026-03-11 21:17 ` brian m. carlson
2026-03-12 6:07 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abFP9vZOVHGI536G@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=r.siddharth.shrimali@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox