Ben Peart <peartben@xxxxxxxxx> writes: > Add test cases that ensure status results are correct when using the new > fsmonitor extension. Test untracked, modified, and new files by > ensuring the results are identical to when not using the extension. > > Add a test to ensure updates to the index properly mark corresponding > entries in the index extension as dirty so that the status is correct > after commands that modify the index but don't trigger changes in the > working directory. > > Add a test that verifies that if the fsmonitor extension doesn't tell > git about a change, it doesn't discover it on its own. This ensures > git is honoring the extension and that we get the performance benefits > desired. > > Signed-off-by: Ben Peart <benpeart@xxxxxxxxxxxxx> > --- > t/t7519-status-fsmonitor.sh | 134 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 134 insertions(+) > create mode 100644 t/t7519-status-fsmonitor.sh Please make this executable. > diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh > new file mode 100644 > index 0000000000..2d63efc27b > --- /dev/null > +++ b/t/t7519-status-fsmonitor.sh > @@ -0,0 +1,134 @@ > ... > +# Ensure commands that call refresh_index() to move the index back in time > +# properly invalidate the fsmonitor cache > +... > + git status >output && > + git -c core.fsmonitor=false status >expect && > + test_i18ncmp expect output > +' Hmm. I wonder if we can somehow detect the case where we got the correct and expected result only because fsmonitor was not in effect, even though the test requested it to be used? Not limited to this particular test piece, but applies to all of them in this file.