Nondeterministic macOS `is_symlink` assertion failure in `overwriting_files_and_lone_directories_works` about gitoxide

[Byron]

Thanks for reporting!

The filesystem probe would be thread-safe (within the worktree-state test-suite) now and I would expect it to be stable - that I have now put to the test as pre-condition.

Otherwise, I don't seem to be able to reproduce the issue locally, neither in single-threaded nor in multi-threaded mode, running it 100 times in short succession.

❯ hyperfine -N -m100 /Users/byron/dev/github.com/Byron/gitoxide/target/debug/deps/worktree-9f25a11ba27ab3a7
Benchmark 1: /Users/byron/dev/github.com/Byron/gitoxide/target/debug/deps/worktree-9f25a11ba27ab3a7
  Time (mean ± σ):     212.4 ms ±  11.5 ms    [User: 113.8 ms, System: 77.8 ms]
  Range (min … max):   204.6 ms … 314.8 ms    100 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

In multi-threaded mode, strangely enough it does appear stable as well.

cargo test -p gix-worktree-state-tests --features gix-features-parallel
❯ hyperfine -N -m100 /Users/byron/dev/github.com/Byron/gitoxide/target/debug/deps/worktree-b64ec3555922d84e
Benchmark 1: /Users/byron/dev/github.com/Byron/gitoxide/target/debug/deps/worktree-b64ec3555922d84e
  Time (mean ± σ):     211.2 ms ±  11.9 ms    [User: 150.0 ms, System: 106.2 ms]
  Range (min … max):   198.2 ms … 322.9 ms    100 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (322.9 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

However, I think the key here is cargo nextest, which runs all tests in parallel, thus making it possible for the 'gitoxide repository probe' to be run in parallel.

This may happen in a few places.

In order to fix this particular issue, I think the probe code should throw a lock down into the repository to use the filesystem for synchronization or, probably better, do synchronization in-process. However, the in-process synchronization is probably not good enough for nextest as it builds all test binaries and then runs them.

An alternative to a lock-file, which I prefer, is to make sure the processes don't step on each others feet, so files they create are uniquely named.

This is certainly the solution we'd have to go for here.