I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527 reliably fails due to what seems to be a race us doing something, and assuming that fsmonitor picked up on it. This makes the tests pass: diff --git a/t/t7527-builtin-fsmonitor.sh b/t/t7527-builtin-fsmonitor.sh index 56c0dfffea..ce2555d558 100755 --- a/t/t7527-builtin-fsmonitor.sh +++ b/t/t7527-builtin-fsmonitor.sh @@ -428,6 +428,7 @@ test_expect_success 'edit some files' ' start_daemon --tf "$PWD/.git/trace" && edit_files && + sleep 1 && test-tool fsmonitor-client query --token 0 && @@ -443,6 +444,7 @@ test_expect_success 'create some files' ' start_daemon --tf "$PWD/.git/trace" && create_files && + sleep 1 && test-tool fsmonitor-client query --token 0 && @@ -471,6 +473,7 @@ test_expect_success 'rename some files' ' start_daemon --tf "$PWD/.git/trace" && rename_files && + sleep 1 && test-tool fsmonitor-client query --token 0 && @@ -978,6 +981,7 @@ test_expect_success !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' ' mkdir test_unicode/nfd/d_${utf8_nfd} && git -C test_unicode fsmonitor--daemon stop && + sleep 1 && if test_have_prereq UNICODE_NFC_PRESERVED then The failure is when we grep out the events we expect, which aren't there, but if you manually inspect them they're there. I.e. they're just not "in" yet. I thought this might be a lack of flushing or syncing in our own trace code, but adding an fsync() to trace_write() didn't do the trick. 1. https://cfarm.tetaneutral.net/news/41#