Git fork

t7815: fix unexpectedly passing test on macOS

In t7815, we have the following test:

test_expect_failure !CYGWIN 'git grep .fi a' '
git grep .fi a
'

The test passes if '.' matches a NUL byte, which we expect to only
happen on Cygwin. The upcoming changes to support parsing TAP output in
Meson surface that this test, surprisingly, passes on macOS as well.

It is unclear how long the test has been passing on macOS already.
064eed36c7f (config.mak.uname: only set NO_REGEX on cygwin for v1.7,
2025-04-17) mentions that the test started to pass for Cygwin. This was
attributed to a new implementation of regcomp(3p) and friends, which was
inherited from FreeBSD. Given the BSD lineage of macOS it is feasible
that it also inherited similar code eventually that made the test pass
now.

It is somewhat dubious what the test actually brings to the table given
that it is quite platform specific. Ideally, we would fix this mess by
having a configure-time check whether regcomp(3p) works as expected,
including NUL bytes, and use our bundled version of the regex library in
case it doesn't. Like this, we could ensure that all platforms work the
same in this edge case and mark the new behaviour as expected.

This change is outside of the scope of this patch series, which only
introduces support for TAP. So instead of fixing the bigger issue,
ignore the test on Darwin like we already do for Cygwin.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

authored by

Patrick Steinhardt and committed by
Junio C Hamano
d3d8c601 d4ea24b8

+4 -1
+1 -1
t/t7815-grep-binary.sh
··· 63 63 git grep ile a 64 64 ' 65 65 66 - test_expect_failure !CYGWIN 'git grep .fi a' ' 66 + test_expect_failure !CYGWIN,!MACOS 'git grep .fi a' ' 67 67 git grep .fi a 68 68 ' 69 69
+3
t/test-lib.sh
··· 1636 1636 # Fix some commands on Windows, and other OS-specific things 1637 1637 uname_s=$(uname -s) 1638 1638 case $uname_s in 1639 + Darwin) 1640 + test_set_prereq MACOS 1641 + ;; 1639 1642 *MINGW*) 1640 1643 # Windows has its own (incompatible) sort and find 1641 1644 sort () {