Byron
Test `overwrite_existing` apparent symlink dereferencing
To investigate #2006, this explodes the occasionally failing test writes_through_symlinks_are_prevented_even_if_overwriting_is_allowed into 1000 identical tests, using test_case::test_matrix.
When run in series, they all pass, but when run in parallel with cargo nextest, some failures always occur, at least when this is done on macOS. This is as predicted in https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2866226601.
A more specific result in local testing on macOS 15 is that, while the number of failures is 0 with --test-threads=1, with 2 or more threads, the number of failures tends to decrease with the number of threads. The most failures occur with --test-threads=2, about 30 on the system tested, while --test-threads=16 has about 10 failures.
The tests were run with this command, with any --test-threads=<N> argument added:
cargo nextest run -p gix-worktree-state-tests writes_through_symlinks_are_prevented_even_if_overwriting_is_allowed --no-fail-fast
See https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2868766118 for substantial further details, including more up to date information covering reproduction on other platforms--it turns out not to be just macOS--and other relevant information and ideas.
(Maybe this PR can turn into a fix, once the cause is figured out. If not, it could be superseded by the fix and closed.)
Regarding 16171b46994001354274bc148cc08c3bf1affb5e, don't worry: I do not plan to merge a new 28-job CI test matrix to main. See EliahKagan#36 for details on these jobs. They surface the failure on GNU/Linux; see https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2878817675.
Note that 16171b46994001354274bc148cc08c3bf1affb5e (EliahKagan#36) doesn't include any changes to how the test uses gix-worktree-state functionality. In particular, it doesn't adjust whether gix-features/parallel is used or the value of the num_threads parameter. That's the next step (https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2881392455). I wanted to add the GNU/Linux repro on CI first, to have greater confidence about the meaning of whatever is observed due to subsequent changes.
Changes related to num_threads, to cause the checkout operation under test to be single-threaded, is now done here in b333ef349b24affdeac17cd728ce1adf246829fe (squashed from EliahKagan#37). I believe this is sufficient to test the scenario anticipated in https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2881392455. However, as can be seen on CI, this does not make the failure go away. See also https://github.com/GitoxideLabs/gitoxide/issues/2006#issuecomment-2888937098.
However, as can be seen on CI, this does not make the failure go away.
This is great!
That means the Rust side of things should be fully deterministic. Either it is not, or there is some filesystem involvement. The only of such reasons (of filesystem involvement) I know is the reliance on traversal order, or possibly relying on mtimes being 'in a certain way'. None of that should matter here though.
