Hi Ævar, On Mon, 18 Mar 2019, Ævar Arnfjörð Bjarmason wrote: > > 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. I finally found some time to track this down (it only took me two days...): it is a racy condition that *hides* the bug. Details and a fix in https://github.com/gitgitgadget/git/pull/223 Ciao, Dscho
