3 new Windows GIX_TEST_IGNORE_ARCHIVES=1 failures with Git 2.48.1 #1849
Labels
acknowledged
an issue is accepted as shortcoming to be fixed
C-Windows
Windows-specific issues
help wanted
Extra attention is needed
Current behavior 😯
When the test suite is run on Windows with
GIX_TEST_IGNORE_ARCHIVES=1
, there are three new failures starting in Git for Windows 2.48.1. I don't know if the problem is in Git for Windows, gitoxide, or gitoxide's test suite:gix-diff-tests::diff index::renames_by_identity
gix-diff-tests::diff tree_with_rewrites::renames_by_identity
gix-merge::merge tree::run_baseline
Those links go to the directly relevant sections of the test output in a gist that contains the full output. The directly relevant sections themselves are:
gix-diff-tests::diff index::renames_by_identity
gix-diff-tests::diff tree_with_rewrites::renames_by_identity
gix-merge::merge tree::run_baseline
In that third test, navigating to
C:/Users/ek/source/repos/gitoxide/gix-merge/tests/fixtures/generated-do-not-edit/tree-baseline/3163911692-windows/rename-add-same-symlink
reveals thatlink
is a symlink pointing totarget
andlink-new
is a regular file. The output ofls
(i.e.Get-ChildItem
, as this is in PowerShell) is:The output of
git status
is:The relevant fixture script code for that test is:
gitoxide/gix-merge/tests/fixtures/tree-baseline.sh
Lines 337 to 355 in 2efce72
This made me wonder if this is no longer taking effect with the version of MSYS2 provided by Git for Windows that provides the Git Bash environment:
gitoxide/tests/tools/src/lib.rs
Lines 620 to 621 in 2efce72
But at least under a cursory examination that does not seem to be broken: I am able to create actual symlinks with
ln -s
when setting that environment variable and invoking thebash
shell provided by Git for Windows, including when version 2.48.1 is installed, and it works whether thebash.exe
I use is the "real"bash
in(git root)/usr/bin
, the Git for Windows wrapper in(git root)/bin
, or thescoop
wrapper that calls the(git root)/bin
wrapper.The run shown and linked above was from PowerShell 7.5. All the same failures, including those three, occur when running the tests on the same system from Git Bash. The same tests will typically pass or fail from either environment, since a
bash.exe
shipped with Git for Windows is used either way since #1712 fixed #1359; these new failures do not go against that expectation.Modifying
gix-testtools
to use a path tobash.exe
in which all directory separators are/
does not affect the results. The test failures do not seem to suggest that this would, but I mention this in case it turns out to be relevant. (The reason I know this is that I discovered this bug while testing such a change on a feature branch, then when rerunning tests on the main branch discovered that it was not caused by that change.)Expected behavior 🤔
Ideally no tests should fail, but the specific expectation that is broken here is that no tests other than the 15 tests known to fail on Windows with
GIX_TEST_IGNORE_ARCHIVE=1
and documented in #1358--one of which is a performance test that does not always fail locally and in practice never fails on CI--should fail.This expectation continues to hold when the test suite is run with Git for Windows 2.47.1(2). Running the tests in otherwise the same local environment matches CI. It is only with Git for Windows 2.48.1 that these three tests fail.
The reason they are not yet failing on CI in the
test-fixtures-windows
job--which since #1663 will reliably detect any such new failures--appears to be that the runner image being used has Git for Windows 2.47.1(2). It seems likely that those new failures will occur on CI once it is upgraded to 2.48.1.Git behavior
A change in Git is involved in triggering this, but I don't know what the change is, nor if the change is itself correct.
git-for-windows/git#5411, which pertains to the 2.48.1 release of Git for Windows, links to git-for-windows/git#5376, which mentions that, for 2.48, Git for Windows integrated some patches from the Git mailing list before they were integrated into the upstream Git. I'm not sure to what extent Git for Windows 2.48.1 has Windows-nonspecific patches that didn't make it upstream yet, though. (The Git for Windows 2.48.1 release page does not list such changes.) Even if Git for Windows 2.48.1 does contain such changes, I do not assume that they would be the cause of this.
Steps to reproduce 🕹
This is mostly detailed above, but the specific commands I used to run the tests in PowerShell were:
And in Git Bash, where the results were the same:
I ran the tests on the main branch at 2efce72 on my main Windows 10 development machine. After initially running them with Git for Windows 2.48.1 installed, I downgraded Git for Windows to 2.47.1(2) and verified that the new failures did not occur, then upgraded it back to 2.48.1 and verified again that they failed again and in the same way. Both versions were installed using
scoop
, from the scoop main bucket. This packages Portable Git. I do not think that the use ofscoop
is important here--the trigger seems to be Git for Windows 2.48.1--but I mention it just in case. I also ran the tests withoutGIX_TEST_IGNORE_ARCHIVES=1
to verify that these tests only fail when that is set.To check if the problem was specific to Windows, I verified that are still no failures on Arch Linux with Git 2.48.1-1 or Git 2.48.1-2, nor on Ubuntu 24.04 LTS with Git 2.48.1-0 from the git-core PPA, including running the tests both with and without
GIX_TEST_IGNORE_ARCHIVES=1
on each. Before each test run, I rangix clean -xde
(not just before the test runs shown above).The text was updated successfully, but these errors were encountered: