Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> Whatever magic you used to fix these failing tests, thanks.
>
> The magic was to pester the maintainers of the dependency of the
> `setup-git-for-windows-sdk` GitHub Action that broke said action.
>
> Background (you can skip this unless you're interested in details):
>
> Since Git's test suite relies so heavily on Unix shell
> scripting, which is really foreign on Windows, we have to use the MSYS2
> Bash to run it. And when I say "MSYS2 Bash", it is short-hand for "a Bash
> that uses the POSIX emulation layer provided by the MSYS2 runtime".
>
> The MSYS2 runtime _does_ have support for actual symbolic links, it just
> depends on certain Windows features (and then it still is not quite the
> same as Unix symbolic links because on Windows, the symbolic links are
> either pointing to files or to directories and you have to specify that
> when creating them).
OK, so bash runtime accidentally enabled symbolic links. But of
course "git" thinks that Windows never do symbolic links by having
{ENOSYS; return -1;} in compat/mingw.h for readlink and symlink,
running any git operation that depends on SYMLINKS prerequisite
would not work and that is where it fails. We do not even have to
hit a test that points a symbolic link at any special file.
Thanks for fixing the environment. The patch in the thread only
meant to ensure that the test suite does not get fooled by only bash
supporting symbolic links without updating "git" supporting any by
being more careful. Now "test -h" and "ln -s" behave without
contradiction with readlink(2)/symlink(2) emulation "git" uses, we
can safely drop it.
