You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have gix-worktree-state checkout tests fail without symlinks
A few of the gix-worktree-state checkout tests have been checking
if the filesystem supports symlinks, while one was skipped (marked
ignored) on Windows based on the idea that symlinks would not be
created, and also had an assertion that assumed symlinks would not
be successfully created.
This commit changes such tests so that they run on all platforms,
including Windows, and so that, on all platforms, they assert that
the filesystem supports symlinks, and assert that expected symlinks
are created after attempts to do so.
(The reason to assert that the filesystem supports symlinks is so
that if this is not detected, either due to a failure or detection
or due to the filesystem really not supporting symlinks, the test
failures will be clear, rather than having a later assertion fail
for unclear reasons.)
Since #1444, tests involving symlinks are expected to work even on
Windows. That PR included changes to the way fixtures were run, and
to other parts of the test suite, to cause symlinks to be created
in cases where they had previously had not (#1443). A number of
tests had been assumed not to work due to limitations of Windows,
MSYS, or Git:
- Although Windows will not allow all users to create symlinks
under all configurations, the test suite expects to be run on a
Windows system configured to permit this.
- Although `ln -s` and similar commands in MSYS environments,
including Git Bash, do not by default attempt to create actual
symlinks, this does happen when symlink creation is enabled using
the `MSYS` environment variable, as done in 0899c2e (#1444).
(This situation differs from that of Unix-style executable bits,
which do not have filesystem support on Windows. While `chmod +x`
and `chmod -x` commands do not take effect on Windows, which
slightly limits the ability to test such metadata and requires
that a number of fixtures set the mode directly in the ndex, with
symlinks there is no such inherent restriction. Provided that
the `MSYS` environment variable is set to allow it, which
gix-testtools takes care of since #1444, and that Windows permits
the user running the test suite to create symlinks, which is
already needed to properly run the test suite on Windows, the
same `ln -s` commands in fixture scripts that work on Unix-like
systems will also work on Windows.)
- Although `git` commands will not check out symlinks as actual
symlinks on Windows unless `core.symlinks` is set to `true`, this
is not typically required for the way symlinks are used in the
gitoixde test suite. Instead, we usually test the presence of
expected symlink metadata in repository data structures such as
an index and trees, as well as the ability of gitoxide to check
out symlinks. (We do not intentionally test the ability to run
`ln -s` in Git Bash, but this is needed in order to create a
number of the repositories for testing. Having `git` check out
symlinks is not typically needed for this.)
In addition, since we are requiring that Windows test
environments permit the user running the test suite to create
symlinks, any failures that arise in the future due to greater
sensitivity to `core.symlinks` (see #1353 for context) could be
worked around by setting that configuration variable for the
tests, either in gix-testtools via `GIT_CONFIG_{COUNT,KEY,VALUE}`
or in the specifically affected fixture scripts.
While #1444 updated a number of tests to reflect the ability to
create symlinks in fixture scripts and the wish to test them on all
platforms including Windows, some tests remain to be updated. This
commit covers the gix-worktree-statte checkout tests.
This does not cover even their associated fixtures, which can
already create symlinks (given the above described conditions), but
that should be updated so they can set intended executable
permissions (see above on `chmod`). This will be done separately.
0 commit comments