Re: [PATCH v3 1/8] t5004: skip SHA-1-only test in SHA-256 repository

[Patrick Steinhardt <ps@pks.im>]

On Wed, Oct 14, 2026 at 05:07:46AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 10:30:27AM +0200, Patrick Steinhardt wrote:
> 
> > We're about to fix that typo in the next commit, but this will also
> > uncover that the above test case is broken when running in SHA-256
> > repositories. The extracted objects are SHA-1 objects, so extracting
> > them into a SHA-256 repository is not going to yield anything good. So
> > once we fix the Fedora-based job to enable breaking changes, which will
> > make tests use SHA-256 by default, the test will break.
> > 
> > Fix this issue by adding the SHA1 prerequisite.
> 
> Does that mean we'll basically never run the test once Git 3.0 shifts to
> sha256 by default? I guess we'll have a sha1 ci job (like we have sha256
> today), but would that job actually hit all the other prereqs?
> 
> If we instead teach it to use its own repo, independent of the defaults,
> then we could run it everywhere (that allows all of the other prereqs).
> 
> Something like:
> 
> diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh
> index 768b0ff85d..3a5c01c475 100755
> --- a/t/t5004-archive-corner-cases.sh
> +++ b/t/t5004-archive-corner-cases.sh
> @@ -187,6 +187,9 @@ test_expect_success EXPENSIVE,UNZIP,UNZIP_ZIP64_SUPPORT \
>  
>  test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
>  	'zip archive with files bigger than 4GB' '
> +	git init --object-format=sha1 big-file &&
> +	(
> +	cd big-file &&
>  	# Pack created with:
>  	#   dd if=/dev/zero of=file bs=1M count=4100 && git hash-object -w file
>  	mkdir -p .git/objects/pack &&
> @@ -206,6 +209,7 @@ test_expect_success EXPENSIVE,LONG_IS_64BIT,UNZIP,UNZIP_ZIP64_SUPPORT,ZIPINFO \
>  	"$GIT_UNZIP" -t big.zip &&
>  	"$ZIPINFO" big.zip >big.lst &&
>  	test_grep $size big.lst
> +	)
>  '
>  
>  build_tree() {
> 
> 
> A real patch obviously would also indent the test body one level; I
> skipped that here to keep the diff readable.

Hmm. Yeah, I guess that wouldn't hurt.

Patrick