patcht4216: fix no-op test that breaks TAP output

6 messages between Jun 19, 2026 and Jun 25, 2026, from Patrick Steinhardt, Taylor Blau, Junio C Hamano, Todd Zullinger.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Patrick SteinhardtJun 19, 2026, 07:20 UTC on lore

In t4216 we have have a prerequisite that is active in case the system's `char` type is signed by default. This prerequisite isn't really used by anything though: while it is used to guard one of our tests, that specific test is essentially a no-op. So all this infrastructure does is to provide some debugging hint to a reader that pays a lot of attention.

Besides that, the way we set up the prerequisite also results in broken TAP output on systems where `char` is unsigned by default: we use `test_cmp()` to diff two files outside of of any test body, and if the files differ we enable the prerequisite. If so, the call to `test_cmp()` would also print output, and that output is of course not valid TAP output.

That wasn't a problem before 389c83025d (t: let prove fail when parsing invalid TAP output, 2026-06-04), because our TAP parser was configured to be lenient. But starting with that commit, t4216 is now failing on systems with unsigned chars.

Drop the whole infrastructure. The prerequisite is not used anywhere else, and the only location where it's used doesn't really provide much value.

Reported-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Hi,

as reported in [1]. Thanks!

Patrick

<20260617220330.n6byiFQr@teonanacatl.net>
---
 t/t4216-log-bloom.sh | 21 ---------------------
 1 file changed, 21 deletions(-)

Show changes to t/t4216-log-bloom.sh +0 −21

diff --git a/t/t4216-log-bloom.sh b/t/t4216-log-bloom.sh
index 1064990de3..16bc39c359 100755
--- a/t/t4216-log-bloom.sh
+++ b/t/t4216-log-bloom.sh
@@ -569,27 +569,6 @@ test_expect_success 'set up repo with high bit path, version 1 changed-path' '
 	git -C highbit1 commit-graph write --reachable --changed-paths
 '
 
-test_expect_success 'setup check value of version 1 changed-path' '
-	(
-		cd highbit1 &&
-		echo "52a9" >expect &&
-		get_first_changed_path_filter >actual
-	)
-'
-
-# expect will not match actual if char is unsigned by default. Write the test
-# in this way, so that a user running this test script can still see if the two
-# files match. (It will appear as an ordinary success if they match, and a skip
-# if not.)
-if test_cmp highbit1/expect highbit1/actual
-then
-	test_set_prereq SIGNED_CHAR_BY_DEFAULT
-fi
-test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
-	# Only the prereq matters for this test.
-	true
-'
-
 test_expect_success 'setup make another commit' '
 	# "git log" does not use Bloom filters for root commits - see how, in
 	# revision.c, rev_compare_tree() (the only code path that eventually calls

---
base-commit: 95e20213faefeb95df29277c58ac1980ab68f701
change-id: 20260619-pks-t4216-drop-unused-prereq-5793107a0249

Taylor BlauJun 19, 2026, 14:04 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] t4216: fix no-op test that breaks TAP output

Hi Patrick,

A couple of thanks are owed: one to Todd for reporting this issue in the first place, another to Peff for analyizing why it didn't appear broken before, and a third for you for proposing a patch to fix it.

If you choose to delete this piece of test infrastructure entirely (I think that there is an alternative direction that I would prefer, but see below for more on why), I think the patch you wrote below is OK.

But...

On Fri, Jun 19, 2026 at 09:20:20AM +0200, Patrick Steinhardt wrote:

Show 5 quoted lines

> In t4216 we have have a prerequisite that is active in case the system's
> `char` type is signed by default. This prerequisite isn't really used by
> anything though: while it is used to guard one of our tests, that
> specific test is essentially a no-op. So all this infrastructure does is
> to provide some debugging hint to a reader that pays a lot of attention.

I don't think that this is guarding nothing, but I agree that the test as written is strange. As I recall, this was to sanity check the v1 Bloom values, but allow failures on platforms where the `char` type is unsigned by default.

I don't feel that strongly about whether or not we check the exact value of the filter, but I think there are a couple of arguments in favor of doing so. Most compelling would be that we know that our murmur3 implementation is correct (in at least one case) and that we don't regress that case in the future. We do have these checks for v2 changed-path Bloom filters where the signed-ness of `char` is irrelevant.

Show 6 quoted lines

> Besides that, the way we set up the prerequisite also results in broken
> TAP output on systems where `char` is unsigned by default: we use
> `test_cmp()` to diff two files outside of of any test body, and if the
> files differ we enable the prerequisite. If so, the call to `test_cmp()`
> would also print output, and that output is of course not valid TAP
> output.

Given this and the above, I would probably err on the side of designating this as 'test_lazy_prereq' or otherwise silencing the output of 'test_cmp' so that this does not taint the TAP output.

Thanks, Taylor

Junio C HamanoJun 19, 2026, 16:29 UTC in reply to Taylor Blau on lore

Re: [PATCH] t4216: fix no-op test that breaks TAP output

Taylor Blau <me@ttaylorr.com> writes:

> Given this and the above, I would probably err on the side of
> designating this as 'test_lazy_prereq' or otherwise silencing the output
> of 'test_cmp' so that this does not taint the TAP output.

We can argue the merit and demerit with a good log message. The central issue at hand is how precious 52a9 in the script lost by this patch is (in other words, are we checking more than "is our char signed or unsigned?").

By the way, I do not quite get the _BY_DEFAULT in the name SIGNED_CHAR_BY_DEFAULT. The builder may have configured to use signed char on a platform that can handle both and their char is by default unsigned, and under such a condition, we would set this prerequisite, even though the default on such a platform is unsigned, no?

Patrick SteinhardtJun 22, 2026, 05:01 UTC in reply to Junio C Hamano on lore

Re: [PATCH] t4216: fix no-op test that breaks TAP output

On Fri, Jun 19, 2026 at 09:29:44AM -0700, Junio C Hamano wrote:

Show 10 quoted lines

> Taylor Blau <me@ttaylorr.com> writes:
> 
> > Given this and the above, I would probably err on the side of
> > designating this as 'test_lazy_prereq' or otherwise silencing the output
> > of 'test_cmp' so that this does not taint the TAP output.
> 
> We can argue the merit and demerit with a good log message.  The
> central issue at hand is how precious 52a9 in the script lost by
> this patch is (in other words, are we checking more than "is our
> char signed or unsigned?").

Ultimately, I don't mind much which way we go. But if we want to retain this, would you mind sending a rewritten v2, Taylor? I feel like you're in a better position to argue why we should retain it.

Thanks!

Patrick

Todd ZullingerJun 25, 2026, 18:51 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] t4216: fix no-op test that breaks TAP output

Patrick Steinhardt wrote:

Show 15 quoted lines

> On Fri, Jun 19, 2026 at 09:29:44AM -0700, Junio C Hamano wrote:
>> Taylor Blau <me@ttaylorr.com> writes:
>> 
>>> Given this and the above, I would probably err on the side of
>>> designating this as 'test_lazy_prereq' or otherwise silencing the output
>>> of 'test_cmp' so that this does not taint the TAP output.
>> 
>> We can argue the merit and demerit with a good log message.  The
>> central issue at hand is how precious 52a9 in the script lost by
>> this patch is (in other words, are we checking more than "is our
>> char signed or unsigned?").
> 
> Ultimately, I don't mind much which way we go. But if we want to retain
> this, would you mind sending a rewritten v2, Taylor? I feel like you're
> in a better position to argue why we should retain it.

Is this something which can be merged before 2.55.0 final? It's certainly not a grave issue, but it is a new test failure for anyone who diligently runs the test suite on many (most?) non-x86 architectures. It seems a shame to punish those folks. :)

FWIW, Tested-by: Todd Zullinger <tmz@pobox.com>

I tested the earlier test_lazy_prereq version as well.

-- 
Todd

Junio C HamanoJun 25, 2026, 20:17 UTC in reply to Todd Zullinger on lore

Re: [PATCH] t4216: fix no-op test that breaks TAP output

Todd Zullinger <tmz@pobox.com> writes:

Show 26 quoted lines

> Patrick Steinhardt wrote:
>> On Fri, Jun 19, 2026 at 09:29:44AM -0700, Junio C Hamano wrote:
>>> Taylor Blau <me@ttaylorr.com> writes:
>>> 
>>>> Given this and the above, I would probably err on the side of
>>>> designating this as 'test_lazy_prereq' or otherwise silencing the output
>>>> of 'test_cmp' so that this does not taint the TAP output.
>>> 
>>> We can argue the merit and demerit with a good log message.  The
>>> central issue at hand is how precious 52a9 in the script lost by
>>> this patch is (in other words, are we checking more than "is our
>>> char signed or unsigned?").
>> 
>> Ultimately, I don't mind much which way we go. But if we want to retain
>> this, would you mind sending a rewritten v2, Taylor? I feel like you're
>> in a better position to argue why we should retain it.
>
> Is this something which can be merged before 2.55.0 final?
> It's certainly not a grave issue, but it is a new test
> failure for anyone who diligently runs the test suite on
> many (most?) non-x86 architectures.  It seems a shame to
> punish those folks. :)
>
> FWIW, Tested-by: Todd Zullinger <tmz@pobox.com>
>
> I tested the earlier test_lazy_prereq version as well.

Good that you pinged, as I forgot that we haven't seen Taylor for some time. Let's merge down Patrick's one you have already tested while leaving it as an option to resurrect the "52a9 is still precious" tweak from Taylor perhaps after the release.

Thanks.