From: Johannes Schindelin Date: Tue, 16 Dec 2025 19:35:05 GMT Subject: Re: [PATCH v3 00/10] Prepare Git's test suite for symbolic link support on Windows Message-ID: In-Reply-To: Hi Junio, On Tue, 16 Dec 2025, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > 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/2d329837e34a88cfe28be728fe24bb5a2c6a9752.1764440906.git.gitgitgadget@gmail.com/ > > > 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` 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 > > Signed-off-by: Johannes Schindelin > > > > ## 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 > >