Re: [PATCH v3 4/6] fsmonitor: add test cases for fsmonitor extension

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/31/2017 12:33 AM, Christian Couder wrote:
+test_expect_success 'refresh_index() invalidates fsmonitor cache' '
+       git config core.fsmonitor true &&
+       git config core.untrackedcache true &&
+       clean_repo &&
+       git status &&
+       test_path_is_missing marker &&
+       dirty_repo &&
+       write_script .git/hooks/query-fsmonitor<<-\EOF &&
+       :>marker
+       EOF
+       git add . &&
+       git commit -m "to reset" &&
+       git status &&
+       test_path_is_file marker &&

Ok so "marker" is there now.

+       git reset HEAD~1 &&
+       git status >output &&
+       test_path_is_file marker &&

You already checked that "marker" exists 3 lines above, and as far as
I can see nothing could remove this file since the previous test, as
the hook can only create it.
So I wonder if something is missing or if this test is redundant.

Testing it each time ensures it is being created when it is supposed to be
(ie when the test believes it is using the query-fsmonitor hook) and that it
isn't when it isn't supposed to be (ie when the hook should not be called).

I would agree with that if the "marker" file was removed after the
previous "test_path_is_file marker", but I don't see any "clean_repo"
or "rm marker" call that removes it.


Got it. I've added a call to "rm -f marker" to ensure the marker isn't left over from the previous status command. I found another instance of where this could happen in "status doesn't detect unreported modifications" and fixed it as well. Thanks!



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]