From: Ben Peart Date: Wed, 31 May 2017 14:57:14 GMT Subject: Re: [PATCH v3 4/6] fsmonitor: add test cases for fsmonitor extension Message-ID: <47d76489-3e2f-ca25-8ff3-4350ca47aa76@gmail.com> In-Reply-To: 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!