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

From: Johannes Schindelin <[email-masked]>
Date: Tue, 16 Dec 2025 20:35:05 +0100 (CET)

Hi Junio,

On Tue, 16 Dec 2025, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <[email-masked]>
> 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.

FWIW this was part of v1 already:
https://lore.kernel.org/git/2d32[email-masked]/

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

That was just an oversight: GitHub continues enumerations on the next
line.

> > Changes since v1:
> > ...
> 
> Curious what the second bullet point was ;-)
> 
> The step [6/10] somehow did not make the list.

Strange. I found a bounce, with this incredibly illuminating message:

	Message rejected. For more information, go to https://support.google.com/mail/answer/69585

That's it. That's the entire message. If you can make any sense of this,
I'd be quite interested to learn something new.

> I can reconstruct it

... by fetching from the tag that is mentioned in the cover letter. That's
what Git is really good at, after all, fetching code changes.

> 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),

... which suggests that I simply made a rebasing mistake and accidentally
dropped the credit, and did not notice it in the range-diff because I had
been staring at the diffs for too long. That's exactly what happened,
please reuse the version from v2.

Ciao,
Johannes

> 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 <[email-masked]>
> >           Signed-off-by: Johannes Schindelin <[email-masked]>
> >       
> >        ## 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
> 
>