Re: [PATCH v3 00/10] Prepare Git's test suite for symbolic link support on Windows

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> It has been a minute or three since the time when Windows versions without
> symbolic link support were common, therefore there are plans to turn on that
> support in the MSYS2 runtime on these Windows versions by default, see
> https://github.com/msys2/msys2-runtime/pull/114 for more details about this.
>
> To prepare for this, I am working toward upstreaming Git for Windows' own
> support for symbolic links. And to prepare for that, in turn, I am hereby
> contributing preemptively the fixes required to eventually let Git's test
> suite pass when both MSYS2 runtime and Git support symbolic links.
>
> As a bonus, this patch series also contains fixes for the Perl tests (which
> were broken for a few years, unnoticed because the CI runs need to save on
> runtime and therefore skip the Perl tests because the consume a lot of
> time).

Great to hear a good news.

> Changes since v2:
>
>  * Polished commit messages.
>  * 
>
> Changes since v1:
> ...

Curious what the second bullet point was ;-)

The step [6/10] somehow did not make the list.  I can reconstruct it
by looking at the range-diff below (i.e., no content changes, just
removal of bunch of lines from the proposed log message and credit
for Patrick), but it briefly made me wonder if steps 6-10 from
posted version left your repository a bit prematurely and they
wanted to have a bit more work on them, to be described on the empty
bullet point (*) line above.

In any case, thanks for updates.  I didn't see anything wrong in
what was shown in the range diff for [01-05/10].  Will replace what
has been queued.

> Range-diff vs v2:
>
>   1:  2d329837e3 =  1:  2d329837e3 t9700: accommodate for Windows paths
>   2:  b97afa9a5c =  2:  b97afa9a5c apply: symbolic links lack a "trustable executable bit"
>   3:  96e279f50e !  3:  f42a2f14bc mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
>      @@ Commit message
>           non-existent file and create it when given above-mentioned flags.
>       
>           Git expects the `open()` call to fail, though. So let's add yet another
>      -    work-around to pretend that Windows behaves like Linux.
>      +    work-around to pretend that Windows behaves according to POSIX, see:
>      +    https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html#:~:text=If%20O_CREAT%20and%20O_EXCL%20are,set%2C%20the%20result%20is%20undefined.
>       
>           This is required to let t4115.8(--reject removes .rej symlink if it
>           exists) pass on Windows when enabling the MSYS2 runtime's symbolic link
>   4:  9639e04ac6 =  4:  70237394c6 t0001: handle `diff --no-index` gracefully
>   5:  3db0599d91 !  5:  0d371ee552 t0301: another fix for Windows compatibility
>      @@ Commit message
>       
>           Just like 0fdcfa2f9f5 (t0301: fixes for windows compatibility,
>           2021-09-14) explained, we should not call `mkdir -m<mode>` in the test
>      -    suite because that would fail on Windows (because Windows has a much
>      -    more powerful permission system that cannot be mapped into the simpler
>      -    user/group/other read/write/execute model).
>      +    suite because that would fail on Windows.
>       
>           There was one forgotten instance of this which was hidden by a `SYMLINK`
>           prerequisite. Currently, this prevents this test case from being
>   6:  f2da7d4d50 !  6:  91bd72062c t0600: fix incomplete prerequisite for a test case
>      @@ Commit message
>           However, the `preferSymlinkRefs` feature is not supported on Windows,
>           therefore this test case needs the `MINGW` prerequisite, too.
>       
>      -    There's a couple more cases where we set this config key:
>      -
>      -      - In a subsequent test in t0600, but there we explicitly set it to
>      -        "false". So this would naturally be supported by Windows.
>      -
>      -      - In t7201 we set the value to `yes`, but we never verify that the
>      -        written reference is a symbolic link in the first place. I guess
>      -        that we could rather remove setting the configuration value here, as
>      -        we are about to deprecate support for symrefs via symbolic links in
>      -        the first place. But that's certainly outside of the scope of this
>      -        patch.
>      -
>      -      - In t9903 we do the same, but likewise, we don't check whether the
>      -        written file is a symbolic link.
>      -
>      -    Therefore this seems to be the only instance where the tests actually
>      -    need to be adapted.
>      -
>      -    Helped-by: Patrick Steinhardt <ps@pks.im>
>           Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>       
>        ## t/t0600-reffiles-backend.sh ##
>   7:  ea74e678f9 =  7:  c2d3212f11 t1006: accommodate for symlink support in MSYS2
>   8:  1619ea4a3b =  8:  03ff6d756d t1305: skip symlink tests that do not apply to Windows
>   9:  807bb679cd =  9:  4ab6aaf2cf t6423: introduce Windows-specific handling for symlinking to /dev/null
>  10:  945306b5d4 = 10:  5f056902df t7800: work around the MSYS path conversion on Windows