Re: [PATCH] test: make SYMLINKS prerequisite more robust

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2023, 18:07 UTC
Message-ID: <xmqq7cwlcucg.fsf@gitster.g>
In-Reply-To: <ef19e164-b0ba-531d-95e6-75ef61c4fc9d@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 17 quoted lines

>> 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.