Thread (2 messages) 2 messages, 2 authors, 2017-05-16

Re: [PATCH v1 3/5] fsmonitor: add test cases for fsmonitor extension

flat view

From: Junio C Hamano <hidden>
Date: 2017-05-16 04:59:38

Ben Peart [off-list ref] 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 <redacted>
---
 t/t7519-status-fsmonitor.sh | 134 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 t/t7519-status-fsmonitor.sh
Please make this executable.
quoted hunk
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help