The test assumes symlinks are never created on Windows. This often
turns out to be correct, because core.symlinks defaults to false on
Windows. (On some Windows systems, creating them is a privileged
operation; this can be reconfigured, and unprivileged creation of
symlinks is often enabled on systems used for development.)

However, on a Windows system with core.symlinks set to true, git
will create symlinks if it can, when checking out entries committed
to a repository as symlinks. GitHub Actions runners for Windows do
this ever since actions/runner-images#1186
(the file is now at images/windows/scripts/build/Install-Git.ps1;
the `/o:EnableSymlinks=Enabled` option continues to be passed,
causing Git for Windows to be installed with core.symlinks set to
true in the system scope).

For now, this adds an xfail marking to test_index_mutation, for the
FileNotFoundError raised when a symlink, which is expected not to
be a symlink, is passed to `open`, causing an attempt to open its
nonexistent target. (The check itself might bear refinement:
currently it reads the core.symlinks variable from any scope,
including the local scope, which at the time of the check will
usually be the cloned GitPython directory, where pytest is run.)

While adding an import, this commit also improves the grouping and
sorting of existing ones.

The test assumes symlinks are never created on Windows. This often
turns out to be correct, because core.symlinks defaults to false on
Windows. (On some Windows systems, creating them is a privileged
operation; this can be reconfigured, and unprivileged creation of
symlinks is often enabled on systems used for development.)

However, on a Windows system with core.symlinks set to true, git
will create symlinks if it can, when checking out entries committed
to a repository as symlinks. GitHub Actions runners for Windows do
this ever since actions/runner-images#1186
(the file is now at images/windows/scripts/build/Install-Git.ps1;
the `/o:EnableSymlinks=Enabled` option continues to be passed,
causing Git for Windows to be installed with core.symlinks set to
true in the system scope).

For now, this adds an xfail marking to test_index_mutation, for the
FileNotFoundError raised when a symlink, which is expected not to
be a symlink, is passed to `open`, causing an attempt to open its
nonexistent target. (The check itself might bear refinement: as
written, it reads the core.symlinks variable from any scope,
including the local scope, which at the time of the check will
usually be the cloned GitPython directory, where pytest is run.)

While adding an import, this commit also improves the grouping and
sorting of existing ones.

The test assumes symlinks are never created on Windows. This often
turns out to be correct, because core.symlinks defaults to false on
Windows. (On some Windows systems, creating them is a privileged
operation; this can be reconfigured, and unprivileged creation of
symlinks is often enabled on systems used for development.)

However, on a Windows system with core.symlinks set to true, git
will create symlinks if it can, when checking out entries committed
to a repository as symlinks. GitHub Actions runners for Windows do
this ever since actions/runner-images#1186
(the file is now at images/windows/scripts/build/Install-Git.ps1;
the `/o:EnableSymlinks=Enabled` option continues to be passed,
causing Git for Windows to be installed with core.symlinks set to
true in the system scope).

For now, this adds an xfail marking to test_index_mutation, for the
FileNotFoundError raised when a symlink, which is expected not to
be a symlink, is passed to `open`, causing an attempt to open its
nonexistent target. (The check itself might bear refinement: as
written, it reads the core.symlinks variable from any scope,
including the local scope, which at the time of the check will
usually be the cloned GitPython directory, where pytest is run.)

While adding an import, this commit also improves the grouping and
sorting of existing ones.