On Wed, Jun 05, 2019 at 10:12:12AM +0200, Johannes Schindelin wrote: > This fails on macOS, in t5601, both in our osx-clang and osx-gcc jobs, as > well as in the StaticAnalysis job. For details, see > https://dev.azure.com/gitgitgadget/git/_build/results?buildId=10206 Hmm. I'm having a hard time seeing why (and I can't seem to reproduce it locally on a case-insensitive HFS+ filesystem under Linux). In particular, if the problem is here: > expecting success: > grep X icasefs/warning && > grep x icasefs/warning && > test_i18ngrep "the following paths have collided" icasefs/warning > > ++ grep X icasefs/warning > error: last command exited with $?=1 > not ok 99 - colliding file detection then that implies it has to do with the checkout phase, which Felipe's patch doesn't touch. Later in the log we see the actual file contents (I'm confused as to how this gets here; it looks like debugging bits that were added after the main script?): 2019-06-05T07:58:37.7961890Z Cloning into 'bogus'... 2019-06-05T07:58:37.7962430Z done. 2019-06-05T07:58:37.7963360Z warning: the following paths have collided (e.g. case-sensitive paths 2019-06-05T07:58:37.7964300Z on a case-insensitive filesystem) and only one from the same 2019-06-05T07:58:37.7964880Z colliding group is in the working tree: 2019-06-05T07:58:37.7965290Z 2019-06-05T07:58:37.7966250Z 'x' whereas a succeeding test expects us to mention both 'x' and 'X'. So we _did_ find the collision, but somehow 'X' was not reported. Looking at the code, I'm not even sure how that could happen. Given that this process does involve looking at stat data, it makes me wonder if there could be some raciness involved. But again, I'm scratching my head as to how exactly, and I couldn't reproduce it under load or with some carefully inserted sleep() calls. And it looks like it did reproduce twice on Azure. Can somebody who has osx locally reproduce this? Or is there a way to interactively access the Azure environment to dig further? > My guess is that your changes remove something that was expected before, > and is still expected, and that this was only tested on Linux, and only on > a file system with case-sensitive file names. It sounds like you're suggesting that changes to the test script subtly affected the later state. Which is indeed a common culprit. But the changes in Felipe's series were all to t5801, not the failing t5601. Am I misunderstanding what you mean? -Peff
