On Sat, Mar 16 2019, Johannes Schindelin via GitGitGadget wrote: > It was reported by Ævar Arnfjörð Bjarmason > [https://public-inbox.org/git/nycvar.QRO.7.76.6.1903142058130.41@xxxxxxxxxxxxxxxxx/T/#mb8718fe52e4721dacd3b143a09187ff9090ef4e3] > that there were problems with the fsmonitor feature in conjunction with the > newly built-in git stash/git rebase. > > The culprit really is that the fsmonitor flag that says whether it was > queried already was not re-set after discard_index() was called by mistake. > > This fixes that, and apparently also other long-standing fsmonitor issues. I've added this to my internal build & now the test suite passes in the fsmonitor mode without any test skipping. > (Note that there is still a flakiness around t7519 > [https://github.com/git-for-windows/git/pull/2127#pullrequestreview-215010574] > where it tries to make sure that the fsmonitor hook can prevent unnecessary > lstat() calls, but that seems to be unrelated to this here bug.) FWIW Since February 1st, 2018 I've run my builds on CentOS [67] through an GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all test and have never encountered this flakyness, and I built pretty much on every "next" push-out. The fix sounds good, just one data point on the rarity of the race in practice. I hadn't noticed this being flaky.