The t7519-status-fsmonitor.sh tests became a lot more flaky with the recent fsmonitor fix (js/fsmonitor-refresh-after-discarding-index). That fix, however, did not introduce the flakiness, but it just made it much more likely to be hit. And it seemed to be hit only on Windows. The reason, though, is that the fsmonitor feature failed to mark the in-memory index as changed, i.e. in need of writing, and it was the has_racy_timestamp() test that hid this bug in most cases (although a lot less on Windows, where the files' mtimes are actually a lot more accurate than on Linux). This fixes https://github.com/gitgitgadget/git/issues/197 Johannes Schindelin (2): fill_stat_cache_info(): prepare for an fsmonitor fix mark_fsmonitor_valid(): mark the index as changed if needed apply.c | 2 +- builtin/update-index.c | 2 +- cache.h | 2 +- diff-lib.c | 2 +- entry.c | 2 +- fsmonitor.h | 5 +++-- preload-index.c | 2 +- read-cache.c | 10 +++++----- 8 files changed, 14 insertions(+), 13 deletions(-) base-commit: aa25c82427ae70aebf3b8f970f2afd54e9a2a8c6 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-223%2Fdscho%2Ffix-racy-fsmonitor-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-223/dscho/fix-racy-fsmonitor-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/223 -- gitgitgadget
