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#
