Skip to content

Commit d715e4a

Browse files
committed
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.
1 parent 9ec034f commit d715e4a

File tree

1 file changed

+4
-18
lines changed

1 file changed

+4
-18
lines changed

gix-worktree-state/tests/state/checkout.rs

Lines changed: 4 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -173,20 +173,13 @@ fn delayed_driver_process() -> crate::Result {
173173
}
174174

175175
#[test]
176-
#[cfg_attr(
177-
windows,
178-
ignore = "on windows, the symlink to a directory doesn't seem to work and we really want to test with symlinks"
179-
)]
180176
fn overwriting_files_and_lone_directories_works() -> crate::Result {
181177
for delay in [
182178
gix_filter::driver::apply::Delay::Allow,
183179
gix_filter::driver::apply::Delay::Forbid,
184180
] {
185181
let mut opts = opts_from_probe();
186-
assert!(
187-
opts.fs.symlink,
188-
"BUG: the probe must detect to be able to generate symlinks"
189-
);
182+
assert!(opts.fs.symlink, "The probe must detect to be able to generate symlinks");
190183
opts.overwrite_existing = true;
191184
opts.filter_process_delay = delay;
192185
opts.destination_is_initially_empty = false;
@@ -244,8 +237,7 @@ fn overwriting_files_and_lone_directories_works() -> crate::Result {
244237
);
245238

246239
let symlink = destination.path().join("dir/sub-dir/symlink");
247-
// on windows, git won't create symlinks as its probe won't detect the capability, even though we do.
248-
assert_eq!(std::fs::symlink_metadata(&symlink)?.is_symlink(), cfg!(unix));
240+
assert!(std::fs::symlink_metadata(&symlink)?.is_symlink());
249241
assert_eq!(
250242
std::fs::read(symlink)?.as_bstr(),
251243
"➡other content\r\n",
@@ -270,10 +262,7 @@ fn symlinks_become_files_if_disabled() -> crate::Result {
270262
#[test]
271263
fn symlinks_to_directories_are_usable() -> crate::Result {
272264
let opts = opts_from_probe();
273-
if !opts.fs.symlink {
274-
eprintln!("Skipping directory symlink test on filesystem that doesn't support it");
275-
return Ok(());
276-
}
265+
assert!(opts.fs.symlink, "The probe must detect to be able to generate symlinks");
277266

278267
let (_source_tree, destination, _index, outcome) =
279268
checkout_index_in_tmp_dir(opts.clone(), "make_dir_symlink", None)?;
@@ -298,10 +287,7 @@ fn symlinks_to_directories_are_usable() -> crate::Result {
298287
#[test]
299288
fn dangling_symlinks_can_be_created() -> crate::Result {
300289
let opts = opts_from_probe();
301-
if !opts.fs.symlink {
302-
eprintln!("Skipping dangling symlink test on filesystem that doesn't support it");
303-
return Ok(());
304-
}
290+
assert!(opts.fs.symlink, "The probe must detect to be able to generate symlinks");
305291

306292
for (fixture, symlink_name, target_name) in [
307293
("make_dangling_symlink", "dangling", "non-existing-target"),

0 commit comments

Comments
 (0)