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

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

[Johannes Schindelin via GitGitGadget]

Git for Windows has supported symbolic links for quite some time: In
https://github.com/git-for-windows/git/pull/156, this support was introduced
already into Git for Windows v2.4.2.windows.1 in May 2015.

However, the Git for Windows CI never ran the test suite with symbolic link
support because the MSYS2 runtime (i.e. the POSIX emulation layer required
to run Git's test suite because the latter is written in Unix shell script)
does not support symbolic links right out of the box. This is for historical
reasons: Symbolic link support was introduced in Windows 7, where these
links could only be created by administrators by default, and it took until
Windows 10 Build 14972 that at least in Developer Mode, non-administrators
would be permitted to create them.

The MSYS2 runtime does have some sort of support for symbolic links,
although with caveats: seeing as it expects the inputs as Unix-like paths,
but the outputs need to be Win32 symbolic links pointing to Win32 paths,
some normalization has to be performed in the process. This leads to
sometimes surprising behavior e.g. when a link target like a/b/.. is
normalized to a.

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

Johannes Schindelin (10):
  t9700: accommodate for Windows paths
  apply: symbolic links lack a "trustable executable bit"
  mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  t0001: handle `diff --no-index` gracefully
  t0301: another fix for Windows compatibility
  t0600: fix incomplete prerequisite for a test case
  t1006: accommodate for symlink support in MSYS2
  t1305: skip symlink tests that do not apply to Windows
  t6423: introduce Windows-specific handling for symlinking to /dev/null
  t7800: work around the MSYS path conversion on Windows

 apply.c                             |  2 +-
 compat/mingw.c                      | 14 ++++++++++++++
 t/t0001-init.sh                     |  5 ++++-
 t/t0301-credential-cache.sh         |  3 ++-
 t/t0600-reffiles-backend.sh         |  2 +-
 t/t1006-cat-file.sh                 | 24 +++++++++++++++++-------
 t/t1305-config-include.sh           |  4 ++--
 t/t6423-merge-rename-directories.sh |  9 +++++++--
 t/t7800-difftool.sh                 |  8 ++++----
 t/t9700/test.pl                     |  9 +++++++--
 10 files changed, 59 insertions(+), 21 deletions(-)


base-commit: 9a2fb147f2c61d0cab52c883e7e26f5b7948e3ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2009%2Fdscho%2Fprepare-the-test-suite-for-symlink-support-on-windows-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2009/dscho/prepare-the-test-suite-for-symlink-support-on-windows-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2009
-- 
gitgitgadget

[PATCH 01/10] t9700: accommodate for Windows paths

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Ever since fe53bbc9beb (Git.pm: Always set Repository to absolute path
if autodetecting, 2009-05-07), the t9700 test _must_ fail on Windows
because of that age-old Unix paths vs Windows paths problem.

The underlying root cause is that Git cannot run with a regular Win32
variant of Perl, the assumption that every path is a Unix path is just
too strong in Git's Perl code.

As a consequence, Git for Windows is basically stuck with using the
MSYS2 variant of Perl which uses a POSIX emulation layer (which is a
friendly fork of Cygwin) _and_ a best-effort Unix <-> Windows paths
conversion whenever crossing the boundary between MSYS2 and regular
Win32 processes. It is best effort only, though, using heuristics to
automagically convert correctly in most cases, but not in all cases.

In the context of this here patch, this means that asking `git.exe` for
the absolute path of the `.git/` directory will return a Win32 path
because `git.exe` is a regular Win32 executable that has no idea about
Unix-ish paths. But above-mentioned commit introduced a test that wants
to verify that this path is identical to the one that the Git Perl
module reports (which refuses to use Win32 paths and uses Unix-ish paths
instead). Obviously, this must fail because no heuristics can kick in at
that layer.

This test failure has not even been caught when Git introduced Windows
support in its CI definition in 2e90484eb4a (ci: add a Windows job to
the Azure Pipelines definition, 2019-01-29), as all tests relying on
Perl had to be disabled even from the start (because the CI runs would
otherwise have resulted in prohibitively long runtimes, not because
Windows is super slow per se, but because Git's test suite keeps
insisting on using technology that requires a POSIX emulation layer,
which _is_ super slow on Windows).

To work around this failure, let's use the `cygpath` utility to convert
the absolute `gitdir` path into the form that the Perl code expects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t9700/test.pl | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 58a9b328d5..570b0c5680 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -117,7 +117,12 @@ close TEMPFILE;
 unlink $tmpfile;
 
 # paths
-is($r->repo_path, $abs_repo_dir . "/.git", "repo_path");
+my $abs_git_dir = $abs_repo_dir . "/.git";
+if ($^O eq 'msys' or $^O eq 'cygwin') {
+  $abs_git_dir = `cygpath -am "$abs_repo_dir/.git"`;
+  $abs_git_dir =~ s/\r?\n?$//;
+}
+is($r->repo_path, $abs_git_dir, "repo_path");
 is($r->wc_path, $abs_repo_dir . "/", "wc_path");
 is($r->wc_subdir, "", "wc_subdir initial");
 $r->wc_chdir("directory1");
@@ -127,7 +132,7 @@ is($r->config("test.string"), "value", "config after wc_chdir");
 # Object generation in sub directory
 chdir("directory2");
 my $r2 = Git->repository();
-is($r2->repo_path, $abs_repo_dir . "/.git", "repo_path (2)");
+is($r2->repo_path, $abs_git_dir, "repo_path (2)");
 is($r2->wc_path, $abs_repo_dir . "/", "wc_path (2)");
 is($r2->wc_subdir, "directory2/", "wc_subdir initial (2)");
 
-- 
gitgitgadget

[PATCH 02/10] apply: symbolic links lack a "trustable executable bit"

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When 0482c32c334b (apply: ignore working tree filemode when
!core.filemode, 2023-12-26) fixed `git apply` to stop warning about
executable files, it inadvertently changed the code flow also for
symbolic links and directories.

Let's narrow the scope of the special `!trust_executable_git` code path
to apply only to regular files.

This is needed to let t4115.5(symlink escape when creating new files)
pass on Windows when symbolic link support is enabled in the MSYS2
runtime.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 apply.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apply.c b/apply.c
index a2ceb3fb40..de5750354a 100644
--- a/apply.c
+++ b/apply.c
@@ -3779,7 +3779,7 @@ static int check_preimage(struct apply_state *state,
 		if (*ce && !(*ce)->ce_mode)
 			BUG("ce_mode == 0 for path '%s'", old_name);
 
-		if (trust_executable_bit)
+		if (trust_executable_bit || !S_ISREG(st->st_mode))
 			st_mode = ce_mode_from_stat(*ce, st->st_mode);
 		else if (*ce)
 			st_mode = (*ce)->ce_mode;
-- 
gitgitgadget

[PATCH 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The `_wopen()` function would gladly follow a symbolic link to a
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.

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index 736a07a028..9fbf12a3d3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
 	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
 	wchar_t wfilename[MAX_PATH];
 	open_fn_t open_fn;
+	WIN32_FILE_ATTRIBUTE_DATA fdata;
 
 	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
 
@@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
 	else if (xutftowcs_path(wfilename, filename) < 0)
 		return -1;
 
+	/*
+	 * When `symlink` exists and is a symbolic link pointing to a
+	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
+	 * create that file. Not what we want: Linux would say `EEXIST`
+	 * in that instance, which is therefore what Git expects.
+	 */
+	if (create &&
+	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
+	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
+		errno = EEXIST;
+		return -1;
+	}
+
 	fd = open_fn(wfilename, oflags, mode);
 
 	/*
-- 
gitgitgadget

Re: [PATCH 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Junio C Hamano]

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

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The `_wopen()` function would gladly follow a symbolic link to a
> 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.

"like Linux" -> "as POSIX expects"?

cf. 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
> support.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  compat/mingw.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 736a07a028..9fbf12a3d3 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
>  	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
>  	wchar_t wfilename[MAX_PATH];
>  	open_fn_t open_fn;
> +	WIN32_FILE_ATTRIBUTE_DATA fdata;
>  
>  	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
>  
> @@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
>  	else if (xutftowcs_path(wfilename, filename) < 0)
>  		return -1;
>  
> +	/*
> +	 * When `symlink` exists and is a symbolic link pointing to a
> +	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
> +	 * create that file. Not what we want: Linux would say `EEXIST`
> +	 * in that instance, which is therefore what Git expects.
> +	 */

"Linux" -> "open() on POSIX-compliant systems".

IOW, _wopen() does not have to behave like POSIX open() and the compat/
layer is how the emulation goes.

FWIW, this is not limited to symbolic links but anything that exists
at the path specified should cause the same EEXIST failure.  The
O_CREAT|O_EXCL combination asks the system to atomically create the
thing anew (or fail).

    O_EXCL
        If O_CREAT and O_EXCL are set, open() shall fail if the file
        exists. The check for the existence of the file and the creation of
        the file if it does not exist shall be atomic with respect to other
        threads executing open() naming the same filename in the same
        directory with O_EXCL and O_CREAT set. If O_EXCL and O_CREAT are
        set, and path names a symbolic link, open() shall fail and set errno
        to [EEXIST], regardless of the contents of the symbolic link. If
        O_EXCL is set and O_CREAT is not set, the result is undefined.

> +	if (create &&
> +	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
> +	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
> +		errno = EEXIST;
> +		return -1;
> +	}
> +
>  	fd = open_fn(wfilename, oflags, mode);
>  
>  	/*

Re: [PATCH 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Johannes Schindelin]

Hi Junio,

On Sat, 29 Nov 2025, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > The `_wopen()` function would gladly follow a symbolic link to a
> > 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.
> 
> "like Linux" -> "as POSIX expects"?
> 
> cf. https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html#:~:text=If%20O_CREAT%20and%20O_EXCL%20are,set%2C%20the%20result%20is%20undefined.

You are both correct and incorrect. The behavior I described indeed is not
limited to Linux, insofar you are correct. The behavior I wanted to
imitate is Linux', though, not POSIX.

I noticed that there was a recent shift, mostly by one particular
contributor on this list, who pushes for POSIX compliance to be the gold
standard Git lives by. However, that does not match my understanding of
what the Git project agreed upon, as documented in
https://gitlab.com/git-scm/git/-/blob/v2.52.0/Documentation/CodingGuidelines?ref_type=tags#L4-6
(and there was no attempt to change this).

As such, I still deem it more appropriate to keep the commit message as I
wrote it, as it matches my intent.

You're of course free to edit the commit message to your liking, as you
have done in the past. It just would not match my intent anymore.

Ciao,
Johannes

> > 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
> > support.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  compat/mingw.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index 736a07a028..9fbf12a3d3 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
> >  	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
> >  	wchar_t wfilename[MAX_PATH];
> >  	open_fn_t open_fn;
> > +	WIN32_FILE_ATTRIBUTE_DATA fdata;
> >  
> >  	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
> >  
> > @@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
> >  	else if (xutftowcs_path(wfilename, filename) < 0)
> >  		return -1;
> >  
> > +	/*
> > +	 * When `symlink` exists and is a symbolic link pointing to a
> > +	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
> > +	 * create that file. Not what we want: Linux would say `EEXIST`
> > +	 * in that instance, which is therefore what Git expects.
> > +	 */
> 
> "Linux" -> "open() on POSIX-compliant systems".
> 
> IOW, _wopen() does not have to behave like POSIX open() and the compat/
> layer is how the emulation goes.
> 
> FWIW, this is not limited to symbolic links but anything that exists
> at the path specified should cause the same EEXIST failure.  The
> O_CREAT|O_EXCL combination asks the system to atomically create the
> thing anew (or fail).
> 
>     O_EXCL
>         If O_CREAT and O_EXCL are set, open() shall fail if the file
>         exists. The check for the existence of the file and the creation of
>         the file if it does not exist shall be atomic with respect to other
>         threads executing open() naming the same filename in the same
>         directory with O_EXCL and O_CREAT set. If O_EXCL and O_CREAT are
>         set, and path names a symbolic link, open() shall fail and set errno
>         to [EEXIST], regardless of the contents of the symbolic link. If
>         O_EXCL is set and O_CREAT is not set, the result is undefined.
> 
> > +	if (create &&
> > +	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
> > +	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
> > +		errno = EEXIST;
> > +		return -1;
> > +	}
> > +
> >  	fd = open_fn(wfilename, oflags, mode);
> >  
> >  	/*
> 

Re: [PATCH 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Junio C Hamano]

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

> On Sat, 29 Nov 2025, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
>> writes:
>> 
>> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
>> >
>> > The `_wopen()` function would gladly follow a symbolic link to a
>> > 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.
>> 
>> "like Linux" -> "as POSIX expects"?
>> 
>> cf. https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html#:~:text=If%20O_CREAT%20and%20O_EXCL%20are,set%2C%20the%20result%20is%20undefined.
>
> You are both correct and incorrect. The behavior I described indeed is not
> limited to Linux, insofar you are correct. The behavior I wanted to
> imitate is Linux', though, not POSIX.

Well, I do not think we require our open() to be so Linux specific
that other POSIX compliant systems (e.g., BSDs) would fail.

Here, Git expects open() to behave as POSIX specifies, so it is good
enough to emulate open() to be sufficiently POSIX, not Linux.
Making it like Linux is purely _your_ doing.

And it would not help future developers who finds this commit by
reading "git log" when they find the code that was changed by this
patch in "git blame" output, and they want to further tweak what is
left by this patch to fit their needs better while trying to avoid
breaking our intent.  Our intention is never "open must work like
Linux, allowing the caller to rely on Linux-specific quirk that
other POSIX implementations may not have", but writing the log as if
"a work-around to make it work like Linux" was necessary will
mislead them.

[PATCH 04/10] t0001: handle `diff --no-index` gracefully

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The test case 're-init to move gitdir symlink' wants to compare the
contents of `newdir/.git`, which is a symbolic link pointing to a file.
However, `git diff --no-index`, which is used by `test_cmp` on Windows,
does not resolve symlinks; It shows the symlink _target_ instead (with a
file mode of 120000). That is totally unexpected by the test case, which
as a consequence fails, meaning that it's a bug in the test case itself.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0001-init.sh | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 618da080dc..2f38e09b58 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -425,7 +425,10 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
 	git init --separate-git-dir ../realgitdir
 	) &&
 	echo "gitdir: $(pwd)/realgitdir" >expected &&
-	test_cmp expected newdir/.git &&
+	case "$GIT_TEST_CMP" in
+	*--no-index*) ;; # git diff --no-index does not resolve symlinks
+	*) test_cmp expected newdir/.git;;
+	esac &&
 	test_cmp expected newdir/here &&
 	test_path_is_dir realgitdir/refs
 '
-- 
gitgitgadget

Re: [PATCH 04/10] t0001: handle `diff --no-index` gracefully

[Junio C Hamano]

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

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The test case 're-init to move gitdir symlink' wants to compare the
> contents of `newdir/.git`, which is a symbolic link pointing to a file.
> However, `git diff --no-index`, which is used by `test_cmp` on Windows,
> does not resolve symlinks; It shows the symlink _target_ instead (with a
> file mode of 120000). That is totally unexpected by the test case, which
> as a consequence fails, meaning that it's a bug in the test case itself.

It is dubious if it is a bug in this particular test case, or
test_cmp implementation that uses "git diff --no-index", though.

Either way, when test_cmp here does not do "diff", the test would
fail, so you are correct to notice that this piece of code needs to
be patched in some way.  I do not think not comparing is the right
solution, though.  Would there be a better option than completely
punting on the comparison?  Something silly like:

> +	case "$GIT_TEST_CMP" in
> +	# git diff --no-index does not resolve symlinks
> +	*--no-index*) cmp expected newdir/.git ;;
> +	*) test_cmp expected newdir/.git ;;
> +	esac &&

perhaps?

> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t0001-init.sh | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index 618da080dc..2f38e09b58 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -425,7 +425,10 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
>  	git init --separate-git-dir ../realgitdir
>  	) &&
>  	echo "gitdir: $(pwd)/realgitdir" >expected &&
> -	test_cmp expected newdir/.git &&
> +	case "$GIT_TEST_CMP" in
> +	*--no-index*) ;; # git diff --no-index does not resolve symlinks
> +	*) test_cmp expected newdir/.git;;
> +	esac &&
>  	test_cmp expected newdir/here &&
>  	test_path_is_dir realgitdir/refs
>  '

Re: [PATCH 04/10] t0001: handle `diff --no-index` gracefully

[Johannes Schindelin]

Hi Junio,

On Sat, 29 Nov 2025, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > The test case 're-init to move gitdir symlink' wants to compare the
> > contents of `newdir/.git`, which is a symbolic link pointing to a file.
> > However, `git diff --no-index`, which is used by `test_cmp` on Windows,
> > does not resolve symlinks; It shows the symlink _target_ instead (with a
> > file mode of 120000). That is totally unexpected by the test case, which
> > as a consequence fails, meaning that it's a bug in the test case itself.
> 
> It is dubious if it is a bug in this particular test case, or
> test_cmp implementation that uses "git diff --no-index", though.
> 
> Either way, when test_cmp here does not do "diff", the test would
> fail, so you are correct to notice that this piece of code needs to
> be patched in some way.  I do not think not comparing is the right
> solution, though.  Would there be a better option than completely
> punting on the comparison?  Something silly like:
> 
> > +	case "$GIT_TEST_CMP" in
> > +	# git diff --no-index does not resolve symlinks
> > +	*--no-index*) cmp expected newdir/.git ;;
> > +	*) test_cmp expected newdir/.git ;;
> > +	esac &&
> 
> perhaps?

Sure. It's not like this adds much confidence, though, as the tested-for
functionality isn't specific to Windows, so I'd expect this to fail on
Linux, too, if it was broken, and running that comparison on Windows does
not add much.

Since you spent time on this, I will change it, though.

Ciao,
Johannes

> 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  t/t0001-init.sh | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> > index 618da080dc..2f38e09b58 100755
> > --- a/t/t0001-init.sh
> > +++ b/t/t0001-init.sh
> > @@ -425,7 +425,10 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
> >  	git init --separate-git-dir ../realgitdir
> >  	) &&
> >  	echo "gitdir: $(pwd)/realgitdir" >expected &&
> > -	test_cmp expected newdir/.git &&
> > +	case "$GIT_TEST_CMP" in
> > +	*--no-index*) ;; # git diff --no-index does not resolve symlinks
> > +	*) test_cmp expected newdir/.git;;
> > +	esac &&
> >  	test_cmp expected newdir/here &&
> >  	test_path_is_dir realgitdir/refs
> >  '
> 

Re: [PATCH 04/10] t0001: handle `diff --no-index` gracefully

[Junio C Hamano]

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

>> > +	case "$GIT_TEST_CMP" in
>> > +	# git diff --no-index does not resolve symlinks
>> > +	*--no-index*) cmp expected newdir/.git ;;
>> > +	*) test_cmp expected newdir/.git ;;
>> > +	esac &&
>> 
>> perhaps?
>
> Sure. It's not like this adds much confidence, though, as the tested-for
> functionality isn't specific to Windows, so I'd expect this to fail on
> Linux, too, if it was broken, and running that comparison on Windows does
> not add much.

It sounds like you are saying running tests on Windows on most of
the platform neutral Git code is waste of resources, and looking at
the number of shareded tests used in CI, it might not be a bad idea
if we can cleanly separate the Git functionality into two categories
(i.e., those that must behave identically on all platforms and
others) and shuffle our tests around to let platforms that runs our
tests slower only the "other" tests, while the faster platform to
run all of them.  But I am not sure if that approach is a practical.

> Since you spent time on this, I will change it, though.

The time I spent does not matter as much as the time other folks
will spend scratching their heads reading the code left by this
patch.  I will be mostly offline this week, so please take your
time.

Thanks.

[PATCH 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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

There was one forgotten instance of this which was hidden by a `SYMLINK`
prerequisite. Currently, this prevents this test case from being
executed on Windows, but with the upcoming support for symbolic links,
it would become a problem.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0301-credential-cache.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
index dc30289f75..6f7cfd9e33 100755
--- a/t/t0301-credential-cache.sh
+++ b/t/t0301-credential-cache.sh
@@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
 		rmdir \"\$HOME/dir/\" &&
 		rm \"\$HOME/.git-credential-cache\"
 	" &&
-	mkdir -p -m 700 "$HOME/dir/" &&
+	mkdir -p "$HOME/dir/" &&
+	chmod 700 "$HOME/dir/" &&
 	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
 	check approve cache <<-\EOF &&
 	protocol=https
-- 
gitgitgadget

Re: [PATCH 05/10] t0301: another fix for Windows compatibility

[Junio C Hamano]

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

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> 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).

But in this case, we are emulating "mkdir -m 700" that is expressed
in a very simpler world view of ugo=rwx with a much more powerful
permission system, isn't it?  If something is more powerful, it
should be easy/possible to emulate a simpler system, I would naively
think.

In any case, a more productive than rethinking the "can we express
what mkdir -m <mode>, which is a construct in a simpler world, wants
to do in terms of a much more powerful permission system?" would be
to see if the test linter can be taught about this particular rule.

It is easy to forget that there is a platform we care about whose
testing environment that emulates POSIX does not like "mkdir -m
700", and it is a bit too much to burden developers to remember.

> There was one forgotten instance of this which was hidden by a `SYMLINK`
> prerequisite. Currently, this prevents this test case from being
> executed on Windows, but with the upcoming support for symbolic links,
> it would become a problem.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t0301-credential-cache.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
> index dc30289f75..6f7cfd9e33 100755
> --- a/t/t0301-credential-cache.sh
> +++ b/t/t0301-credential-cache.sh
> @@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
>  		rmdir \"\$HOME/dir/\" &&
>  		rm \"\$HOME/.git-credential-cache\"
>  	" &&
> -	mkdir -p -m 700 "$HOME/dir/" &&
> +	mkdir -p "$HOME/dir/" &&
> +	chmod 700 "$HOME/dir/" &&

That "mkdir -p -m 700" is a no-no while "mkdir -p" followed by
"chmod 700" is OK is a bit puzzling, but I assume $HOME does exist
in the testing envioronment, so this new sequence should be
equivalent in the simpler permission system.  If it works fine on
Windows, that is great.

>  	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
>  	check approve cache <<-\EOF &&
>  	protocol=https

Re: [PATCH 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin]

Hi Junio,

On Sat, 29 Nov 2025, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > 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).
> 
> But in this case, we are emulating "mkdir -m 700" that is expressed
> in a very simpler world view of ugo=rwx with a much more powerful
> permission system, isn't it?  If something is more powerful, it
> should be easy/possible to emulate a simpler system, I would naively
> think.

It is probably outside the purview of this patch series to question why
Cygwin's `mkdir -m` doesn't emulate Unix semantics let alone to fix it. So
I'll bow out of that tangent.

> In any case, a more productive than rethinking the "can we express
> what mkdir -m <mode>, which is a construct in a simpler world, wants
> to do in terms of a much more powerful permission system?" would be
> to see if the test linter can be taught about this particular rule.

Seeing that this issue had to be fixed twice within the course of over 4
years, https://xkcd.com/1205/ applies.

Ciao,
Johannes

> 
> It is easy to forget that there is a platform we care about whose
> testing environment that emulates POSIX does not like "mkdir -m
> 700", and it is a bit too much to burden developers to remember.
> 
> > There was one forgotten instance of this which was hidden by a `SYMLINK`
> > prerequisite. Currently, this prevents this test case from being
> > executed on Windows, but with the upcoming support for symbolic links,
> > it would become a problem.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  t/t0301-credential-cache.sh | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
> > index dc30289f75..6f7cfd9e33 100755
> > --- a/t/t0301-credential-cache.sh
> > +++ b/t/t0301-credential-cache.sh
> > @@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
> >  		rmdir \"\$HOME/dir/\" &&
> >  		rm \"\$HOME/.git-credential-cache\"
> >  	" &&
> > -	mkdir -p -m 700 "$HOME/dir/" &&
> > +	mkdir -p "$HOME/dir/" &&
> > +	chmod 700 "$HOME/dir/" &&
> 
> That "mkdir -p -m 700" is a no-no while "mkdir -p" followed by
> "chmod 700" is OK is a bit puzzling, but I assume $HOME does exist
> in the testing envioronment, so this new sequence should be
> equivalent in the simpler permission system.  If it works fine on
> Windows, that is great.
> 
> >  	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
> >  	check approve cache <<-\EOF &&
> >  	protocol=https
> 

Re: [PATCH 05/10] t0301: another fix for Windows compatibility

[Junio C Hamano]

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

>> In any case, a more productive than rethinking the "can we express
>> what mkdir -m <mode>, which is a construct in a simpler world, wants
>> to do in terms of a much more powerful permission system?" would be
>> to see if the test linter can be taught about this particular rule.
>
> Seeing that this issue had to be fixed twice within the course of over 4
> years, https://xkcd.com/1205/ applies.

It means that we are punting and are not proactively helping future
developers who may make the same mistake, but we expect it would be
rather rare so I am OK with us making that trade-off.  But then can
you dial back your condescending tone against those who are not as
familiar as glitches in the Windows port of POSIX shell environment
we use for tests?

Thanks.

>> It is easy to forget that there is a platform we care about whose
>> testing environment that emulates POSIX does not like "mkdir -m
>> 700", and it is a bit too much to burden developers to remember.

Re: [PATCH 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin]

Hi Junio,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> In any case, a more productive than rethinking the "can we express
> >> what mkdir -m <mode>, which is a construct in a simpler world, wants
> >> to do in terms of a much more powerful permission system?" would be
> >> to see if the test linter can be taught about this particular rule.
> >
> > Seeing that this issue had to be fixed twice within the course of over 4
> > years, https://xkcd.com/1205/ applies.
> 
> It means that we are punting and are not proactively helping future
> developers who may make the same mistake, but we expect it would be
> rather rare so I am OK with us making that trade-off.

Good, then we're on the same page regarding this approach.

> But then can you dial back your condescending tone against those who are
> not as familiar as glitches in the Windows port of POSIX shell
> environment we use for tests?

Please don't read more into my words than merely a large frustration with
the state of Git's test suite. It might be mostly conforming to the 80
character per line convention, yet I yearn instead for the same speed,
readability, portability and debuggability that I've encountered in other
projects' test suites.

Ciao,
Johannes

Re: [PATCH 05/10] t0301: another fix for Windows compatibility

[Junio C Hamano]

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

>> It means that we are punting and are not proactively helping future
>> developers who may make the same mistake, but we expect it would be
>> rather rare so I am OK with us making that trade-off.
>
> Good, then we're on the same page regarding this approach.
>
>> But then can you dial back your condescending tone against those who are
>> not as familiar as glitches in the Windows port of POSIX shell
>> environment we use for tests?
>
> Please don't read more into my words than merely a large frustration with
> the state of Git's test suite.

Well, the proposed log message is to help future readers of "git
log" by explaining the relevant background of what motivated us to
make the change.  Knowing that you were frustrated may make them
sympathize, but it would not help them make robust technical
decisions when they need to further change what the patch leaves
with us.  At that point, telling them our intentions would help them
avoid breaking us while making the end-result fit better for their
purpose.  Do we want them to be extra careful not to frustrate you
specifically when they make a follow-on work in the same area, or
something?

[PATCH 06/10] t0600: fix incomplete prerequisite for a test case

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The 'symref transaction supports symlinks' test case is guarded by the
`SYMLINK` prerequisite because `core.prefersymlinkrefs = true` requires
symbolic links to be supported.

However, the `preferSymlinkRefs` feature is not supported on Windows,
therefore this test case needs the `MINGW` prerequisite, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0600-reffiles-backend.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
index b11126ed47..74bfa2e9ba 100755
--- a/t/t0600-reffiles-backend.sh
+++ b/t/t0600-reffiles-backend.sh
@@ -467,7 +467,7 @@ test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
 	esac
 '
 
-test_expect_success SYMLINKS 'symref transaction supports symlinks' '
+test_expect_success SYMLINKS,!MINGW 'symref transaction supports symlinks' '
 	test_when_finished "git symbolic-ref -d TEST_SYMREF_HEAD" &&
 	git update-ref refs/heads/new @ &&
 	test_config core.prefersymlinkrefs true &&
-- 
gitgitgadget

Re: [PATCH 06/10] t0600: fix incomplete prerequisite for a test case

[Patrick Steinhardt]

On Sat, Nov 29, 2025 at 06:28:22PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The 'symref transaction supports symlinks' test case is guarded by the
> `SYMLINK` prerequisite because `core.prefersymlinkrefs = true` requires
> symbolic links to be supported.
> 
> However, the `preferSymlinkRefs` feature is not supported on Windows,
> therefore this test case needs the `MINGW` prerequisite, too.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t0600-reffiles-backend.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
> index b11126ed47..74bfa2e9ba 100755
> --- a/t/t0600-reffiles-backend.sh
> +++ b/t/t0600-reffiles-backend.sh
> @@ -467,7 +467,7 @@ test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
>  	esac
>  '
>  
> -test_expect_success SYMLINKS 'symref transaction supports symlinks' '
> +test_expect_success SYMLINKS,!MINGW 'symref transaction supports symlinks' '
>  	test_when_finished "git symbolic-ref -d TEST_SYMREF_HEAD" &&
>  	git update-ref refs/heads/new @ &&
>  	test_config core.prefersymlinkrefs true &&

Makes sense. 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
    series.

  - In t9903 we do the same, but likewise, we don't check whether the
    written file is a symbolic link.

So yes, this seems to be the only instance where we actually need to
adapt tests.

Thanks!

Patrick

Re: [PATCH 06/10] t0600: fix incomplete prerequisite for a test case

[Johannes Schindelin]

Hi Patrick,

On Mon, 1 Dec 2025, Patrick Steinhardt wrote:

> On Sat, Nov 29, 2025 at 06:28:22PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > The 'symref transaction supports symlinks' test case is guarded by the
> > `SYMLINK` prerequisite because `core.prefersymlinkrefs = true` requires
> > symbolic links to be supported.
> > 
> > However, the `preferSymlinkRefs` feature is not supported on Windows,
> > therefore this test case needs the `MINGW` prerequisite, too.
> > 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  t/t0600-reffiles-backend.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
> > index b11126ed47..74bfa2e9ba 100755
> > --- a/t/t0600-reffiles-backend.sh
> > +++ b/t/t0600-reffiles-backend.sh
> > @@ -467,7 +467,7 @@ test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
> >  	esac
> >  '
> >  
> > -test_expect_success SYMLINKS 'symref transaction supports symlinks' '
> > +test_expect_success SYMLINKS,!MINGW 'symref transaction supports symlinks' '
> >  	test_when_finished "git symbolic-ref -d TEST_SYMREF_HEAD" &&
> >  	git update-ref refs/heads/new @ &&
> >  	test_config core.prefersymlinkrefs true &&
> 
> Makes sense. 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
>     series.
> 
>   - In t9903 we do the same, but likewise, we don't check whether the
>     written file is a symbolic link.
> 
> So yes, this seems to be the only instance where we actually need to
> adapt tests.

Thank you for doing my homework. I meant to jot it down in my TODO list as
something that I needed to check before sending the series, but I forgot
to jot it down and therefore forgot.

Thanks again!
Johannes

[PATCH 07/10] t1006: accommodate for symlink support in MSYS2

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The MSYS2 runtime (which inherits this trait from the Cygwin runtime,
and which is used by Git for Windows' Bash to emulate POSIX
functionality on Windows, the same Bash that is also used to run Git's
test suite on Windows) has a mode where it can create native symbolic
links on Windows.

Naturally, this is a bit of a strange feature, given that Cygwin goes
out of its way to support Unix-like paths even if no Win32 program
understands those, and the symbolic links have to use Win32 paths
instead (which Win32 programs understand very well).

As a consequence, the symbolic link targets get normalized before the
links are created.

This results in certain quirks that Git's test suite is ill equipped to
accommodate (because Git's test suite expects to be able to use
Unix-like paths even on Windows).

The test script t1006-cat-file.sh contains two prime examples, two test
cases that need to skip a couple assertions because they are simply
wrong in the context of Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1006-cat-file.sh | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index 1f61b666a7..0eee3bb878 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -1048,18 +1048,28 @@ test_expect_success 'git cat-file --batch-check --follow-symlinks works for out-
 	echo .. >>expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual &&
-	echo symlink 3 >expect &&
-	echo ../ >>expect &&
+	if test_have_prereq MINGW,SYMLINKS
+	then
+		test_write_lines "symlink 2" ..
+	else
+		test_write_lines "symlink 3" ../
+	fi >expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir-trailing | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual
 '
 
 test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
-	echo HEAD: | git cat-file --batch-check >expect &&
-	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
-	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
+	if test_have_prereq !MINGW
+	then
+		# The `up-down` and `up-down-trailing` symlinks are normalized
+		# in MSYS in `winsymlinks` mode and are therefore in a
+		# different shape than Git expects them.
+		echo HEAD: | git cat-file --batch-check >expect &&
+		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual &&
+		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual
+	fi &&
 	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp found actual &&
 	echo symlink 7 >expect &&
-- 
gitgitgadget

Re: [PATCH 07/10] t1006: accommodate for symlink support in MSYS2

[Patrick Steinhardt]

On Sat, Nov 29, 2025 at 06:28:23PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index 1f61b666a7..0eee3bb878 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -1048,18 +1048,28 @@ test_expect_success 'git cat-file --batch-check --follow-symlinks works for out-
>  	echo .. >>expect &&
>  	echo HEAD:dir/subdir/out-of-repo-link-dir | git cat-file --batch-check --follow-symlinks >actual &&
>  	test_cmp expect actual &&
> -	echo symlink 3 >expect &&
> -	echo ../ >>expect &&
> +	if test_have_prereq MINGW,SYMLINKS
> +	then
> +		test_write_lines "symlink 2" ..
> +	else
> +		test_write_lines "symlink 3" ../
> +	fi >expect &&
>  	echo HEAD:dir/subdir/out-of-repo-link-dir-trailing | git cat-file --batch-check --follow-symlinks >actual &&
>  	test_cmp expect actual
>  '

Okay.

>  test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
> -	echo HEAD: | git cat-file --batch-check >expect &&
> -	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> -	test_cmp expect actual &&
> -	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> -	test_cmp expect actual &&
> +	if test_have_prereq !MINGW
> +	then
> +		# The `up-down` and `up-down-trailing` symlinks are normalized
> +		# in MSYS in `winsymlinks` mode and are therefore in a
> +		# different shape than Git expects them.
> +		echo HEAD: | git cat-file --batch-check >expect &&
> +		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> +		test_cmp expect actual &&
> +		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> +		test_cmp expect actual
> +	fi &&
>  	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
>  	test_cmp found actual &&
>  	echo symlink 7 >expect &&

I'm not quite sure I follow, so my questions may be dumb. Does this mean
that git-cat-file(1) fails to follow the symlink in this case, and
consequently we cannot execute it at all? If so, is this a bug that
we'll eventually have to fix?

If this is something we can fix it could be sensible to have an `else`
branch that documents the failure case. In that case, we would then
notice that the test fails once we fix the underlying issue.

Patrick

Re: [PATCH 07/10] t1006: accommodate for symlink support in MSYS2

[Johannes Schindelin]

Hi Patrick,

On Mon, 1 Dec 2025, Patrick Steinhardt wrote:

> On Sat, Nov 29, 2025 at 06:28:23PM +0000, Johannes Schindelin via GitGitGadget wrote:
> 
> >  test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
> > -	echo HEAD: | git cat-file --batch-check >expect &&
> > -	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> > -	test_cmp expect actual &&
> > -	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> > -	test_cmp expect actual &&
> > +	if test_have_prereq !MINGW
> > +	then
> > +		# The `up-down` and `up-down-trailing` symlinks are normalized
> > +		# in MSYS in `winsymlinks` mode and are therefore in a
> > +		# different shape than Git expects them.
> > +		echo HEAD: | git cat-file --batch-check >expect &&
> > +		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> > +		test_cmp expect actual &&
> > +		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> > +		test_cmp expect actual
> > +	fi &&
> >  	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
> >  	test_cmp found actual &&
> >  	echo symlink 7 >expect &&
> 
> I'm not quite sure I follow, so my questions may be dumb. Does this mean
> that git-cat-file(1) fails to follow the symlink in this case, and
> consequently we cannot execute it at all? If so, is this a bug that
> we'll eventually have to fix?

No, it means that the symbolic links are not even created in the way Git's
test suite thinks they are (or should be) created. The way those symbolic
link targets exist on disk (i.e. the way Cygwin's
`winsymlinks:nativestrict` mode constructs them), the expectations of this
test cannot be met, no matter what `cat-file` does.

Ciao,
Johannes

Re: [PATCH 07/10] t1006: accommodate for symlink support in MSYS2

[Patrick Steinhardt]

On Mon, Dec 01, 2025 at 02:29:45PM +0100, Johannes Schindelin wrote:
> Hi Patrick,
> 
> On Mon, 1 Dec 2025, Patrick Steinhardt wrote:
> 
> > On Sat, Nov 29, 2025 at 06:28:23PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > 
> > >  test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
> > > -	echo HEAD: | git cat-file --batch-check >expect &&
> > > -	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> > > -	test_cmp expect actual &&
> > > -	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> > > -	test_cmp expect actual &&
> > > +	if test_have_prereq !MINGW
> > > +	then
> > > +		# The `up-down` and `up-down-trailing` symlinks are normalized
> > > +		# in MSYS in `winsymlinks` mode and are therefore in a
> > > +		# different shape than Git expects them.
> > > +		echo HEAD: | git cat-file --batch-check >expect &&
> > > +		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
> > > +		test_cmp expect actual &&
> > > +		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
> > > +		test_cmp expect actual
> > > +	fi &&
> > >  	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
> > >  	test_cmp found actual &&
> > >  	echo symlink 7 >expect &&
> > 
> > I'm not quite sure I follow, so my questions may be dumb. Does this mean
> > that git-cat-file(1) fails to follow the symlink in this case, and
> > consequently we cannot execute it at all? If so, is this a bug that
> > we'll eventually have to fix?
> 
> No, it means that the symbolic links are not even created in the way Git's
> test suite thinks they are (or should be) created. The way those symbolic
> link targets exist on disk (i.e. the way Cygwin's
> `winsymlinks:nativestrict` mode constructs them), the expectations of this
> test cannot be met, no matter what `cat-file` does.

Ah, makes sense. Thanks for clarifying!

Patrick

[PATCH 08/10] t1305: skip symlink tests that do not apply to Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In Git for Windows, the gitdir is canonicalized so that even when the
gitdir is specified via a symbolic link, the `gitdir:` conditional
include will only match the real directory path.

Unfortunately, t1305 codifies a different behavior in two test cases,
which are hereby skipped on Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1305-config-include.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 8ff2b0c232..6e51f892f3 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -286,7 +286,7 @@ test_expect_success SYMLINKS 'conditional include, relative path with symlinks'
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink' '
 	ln -s foo bar &&
 	(
 		cd bar &&
@@ -298,7 +298,7 @@ test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink, icase' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink, icase' '
 	(
 		cd bar &&
 		echo "[includeIf \"gitdir/i:BAR/\"]path=bar8" >>.git/config &&
-- 
gitgitgadget

[PATCH 09/10] t6423: introduce Windows-specific handling for symlinking to /dev/null

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The device `/dev/null` does not exist on Windows, it's called `NUL`
there. Calling `ln -s /dev/null my-symlink` in a symlink-enabled MSYS2
Bash will therefore literally link to a file or directory called `null`
that is supposed to be in the current drive's top-level `dev` directory.
Which typically does not exist.

The test, however, really wants the created symbolic link to point to
the NUL device. Let's instead use the `mklink` utility on Windows to
perform that job, and keep using `ln -s /dev/null <target>` on
non-Windows platforms.

While at it, add the missing `SYMLINKS` prereq because this test _still_
would not pass on Windows before support for symbolic links is
upstreamed from Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t6423-merge-rename-directories.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
index 533ac85dc8..53535a8ebf 100755
--- a/t/t6423-merge-rename-directories.sh
+++ b/t/t6423-merge-rename-directories.sh
@@ -5158,13 +5158,18 @@ test_setup_12m () {
 		git switch B &&
 		git rm dir/subdir/file &&
 		mkdir dir &&
-		ln -s /dev/null dir/subdir &&
+		if test_have_prereq MINGW
+		then
+			cmd //c 'mklink dir\subdir NUL'
+		else
+			ln -s /dev/null dir/subdir
+		fi &&
 		git add . &&
 		git commit -m "B"
 	)
 }
 
-test_expect_success '12m: Change parent of renamed-dir to symlink on other side' '
+test_expect_success SYMLINKS '12m: Change parent of renamed-dir to symlink on other side' '
 	test_setup_12m &&
 	(
 		cd 12m &&
-- 
gitgitgadget

[PATCH 10/10] t7800: work around the MSYS path conversion on Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git's test suite's relies on Unix shell scripting, which is
understandable, of course, given Git's firm roots (and indeed, ongoing
focus) on Linux.

This fact, combined with Unix shell scripting's natural
habitat -- which is, naturally... *drumroll*... Unix --
often has unintended side effects, where developers expect the test
suite to run in a Unix environment, which is an incorrect assumption.

One instance of this problem can be observed in the 'difftool --dir-diff
handles modified symlinks' test case in `t7800-difftool.sh`, which
assumes that that all absolute paths start with a forward slash. That
assumption is incorrect in general, e.g. on Windows, where absolute
paths have many shapes and forms, none of which starts with a forward
slash.

The only saving grace is that this test case is currently not run on
Windows because of the `SYMLINK` prerequisite. However, I am currently
working towards upstreaming symbolic link support from Git for Windows
to upstream Git, which will put a crack into that saving grace.

Let's change that test case so that it does not rely on absolute paths
(which are passed to the "external command" `ls` as parameters and are
therefore part of its output, and which the test case wants to filter
out before verifying that the output is as expected) starting with a
forward slash. Let's instead rely on the much more reliable fact that
`ls` will output the path in a line that ends in a colon, and simply
filter out those lines by matching said colon instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7800-difftool.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 9b74db5563..bf0f67378d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -752,11 +752,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 		c
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	# The left side contains symlink "c" that points to "b"
@@ -786,11 +786,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual
 '
 
-- 
gitgitgadget

Re: [PATCH 10/10] t7800: work around the MSYS path conversion on Windows

[Junio C Hamano]

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

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Git's test suite's relies on Unix shell scripting, which is
> understandable, of course, given Git's firm roots (and indeed, ongoing
> focus) on Linux.
>
> This fact, combined with Unix shell scripting's natural
> habitat -- which is, naturally... *drumroll*... Unix --
> often has unintended side effects, where developers expect the test
> suite to run in a Unix environment, which is an incorrect assumption.

Surely, those who are primarily on Linux, or those whose background
is from other kinds of UNIX, cannot be expected to be intimately
familiar with how the POSIX shell script environment ported to
Windows platform behaves, and it is understandable if they expect,
as a port, it would behave more or less the same way as they are
accustomed to on UNIX.  Even though POSIX shell script environment
used to run our end-to-end tests are ported to Windows, however, the
scripts still need to be aware of certain things that have to be
done differently in Windows environment from how they are done in
UNIX environment.  Here what you fixed, the absolute pathname may
begin with <drive> <colon> instead of <slash>, may be one of them.

And these differences are not necessarily well known and/or
advertised to many of the developers who have written our tests on
Linux or macOS over time.  I wonder if we can do something about
that, instead of reacting to breakage retroactively while
complaining with disgust about the platform differences, which is
what we often have to see on this list.

> Let's instead rely on the much more reliable fact that
> `ls` will output the path in a line that ends in a colon, and simply
> filter out those lines by matching said colon instead.

That is clever and clean, a very well crafted solution.

Will queue.  The entire series looked quite sensibly reasoned.

Thanks.

Re: [PATCH 10/10] t7800: work around the MSYS path conversion on Windows

[Eric Sunshine]

On Sat, Nov 29, 2025 at 1:29 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> Git's test suite's relies on Unix shell scripting, which is
> understandable, of course, given Git's firm roots (and indeed, ongoing
> focus) on Linux.
>
> This fact, combined with Unix shell scripting's natural
> habitat -- which is, naturally... *drumroll*... Unix --
> often has unintended side effects, where developers expect the test
> suite to run in a Unix environment, which is an incorrect assumption.
>
> One instance of this problem can be observed in the 'difftool --dir-diff
> handles modified symlinks' test case in `t7800-difftool.sh`, which
> assumes that that all absolute paths start with a forward slash. That

s/that that/that/

> assumption is incorrect in general, e.g. on Windows, where absolute
> paths have many shapes and forms, none of which starts with a forward
> slash.
>
> The only saving grace is that this test case is currently not run on
> Windows because of the `SYMLINK` prerequisite. However, I am currently
> working towards upstreaming symbolic link support from Git for Windows
> to upstream Git, which will put a crack into that saving grace.
>
> Let's change that test case so that it does not rely on absolute paths
> (which are passed to the "external command" `ls` as parameters and are
> therefore part of its output, and which the test case wants to filter
> out before verifying that the output is as expected) starting with a
> forward slash. Let's instead rely on the much more reliable fact that
> `ls` will output the path in a line that ends in a colon, and simply
> filter out those lines by matching said colon instead.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Re: [PATCH 10/10] t7800: work around the MSYS path conversion on Windows

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Hi Eric,

On Sun, 30 Nov 2025, Eric Sunshine wrote:

> On Sat, Nov 29, 2025 at 1:29 PM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> > Git's test suite's relies on Unix shell scripting, which is
> > understandable, of course, given Git's firm roots (and indeed, ongoing
> > focus) on Linux.
> >
> > This fact, combined with Unix shell scripting's natural
> > habitat -- which is, naturally... *drumroll*... Unix --
> > often has unintended side effects, where developers expect the test
> > suite to run in a Unix environment, which is an incorrect assumption.
> >
> > One instance of this problem can be observed in the 'difftool --dir-diff
> > handles modified symlinks' test case in `t7800-difftool.sh`, which
> > assumes that that all absolute paths start with a forward slash. That
> 
> s/that that/that/

Thanks,
Johannes

> 
> > assumption is incorrect in general, e.g. on Windows, where absolute
> > paths have many shapes and forms, none of which starts with a forward
> > slash.
> >
> > The only saving grace is that this test case is currently not run on
> > Windows because of the `SYMLINK` prerequisite. However, I am currently
> > working towards upstreaming symbolic link support from Git for Windows
> > to upstream Git, which will put a crack into that saving grace.
> >
> > Let's change that test case so that it does not rely on absolute paths
> > (which are passed to the "external command" `ls` as parameters and are
> > therefore part of its output, and which the test case wants to filter
> > out before verifying that the output is as expected) starting with a
> > forward slash. Let's instead rely on the much more reliable fact that
> > `ls` will output the path in a line that ends in a colon, and simply
> > filter out those lines by matching said colon instead.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> 

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

[Johannes Schindelin via GitGitGadget]

Git for Windows has supported symbolic links for quite some time: In
https://github.com/git-for-windows/git/pull/156, this support was introduced
already into Git for Windows v2.4.2.windows.1 in May 2015.

However, the Git for Windows CI never ran the test suite with symbolic link
support because the MSYS2 runtime (i.e. the POSIX emulation layer required
to run Git's test suite because the latter is written in Unix shell script)
does not support symbolic links right out of the box. This is for historical
reasons: Symbolic link support was introduced in Windows 7, where these
links could only be created by administrators by default, and it took until
Windows 10 Build 14972 that at least in Developer Mode, non-administrators
would be permitted to create them.

The MSYS2 runtime does have some sort of support for symbolic links,
although with caveats: seeing as it expects the inputs as Unix-like paths,
but the outputs need to be Win32 symbolic links pointing to Win32 paths,
some normalization has to be performed in the process. This leads to
sometimes surprising behavior e.g. when a link target like a/b/.. is
normalized to a.

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

Changes since v1:

 * Fixed a grammar issue.
 * Using cmp rather than skipping the comparison (thanks Junio).
 * Extended a commit message to explain that it covers all the cases where
   core.preferSymlinkRefs needs special care.

Johannes Schindelin (10):
  t9700: accommodate for Windows paths
  apply: symbolic links lack a "trustable executable bit"
  mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  t0001: handle `diff --no-index` gracefully
  t0301: another fix for Windows compatibility
  t0600: fix incomplete prerequisite for a test case
  t1006: accommodate for symlink support in MSYS2
  t1305: skip symlink tests that do not apply to Windows
  t6423: introduce Windows-specific handling for symlinking to /dev/null
  t7800: work around the MSYS path conversion on Windows

 apply.c                             |  2 +-
 compat/mingw.c                      | 14 ++++++++++++++
 t/t0001-init.sh                     |  6 +++++-
 t/t0301-credential-cache.sh         |  3 ++-
 t/t0600-reffiles-backend.sh         |  2 +-
 t/t1006-cat-file.sh                 | 24 +++++++++++++++++-------
 t/t1305-config-include.sh           |  4 ++--
 t/t6423-merge-rename-directories.sh |  9 +++++++--
 t/t7800-difftool.sh                 |  8 ++++----
 t/t9700/test.pl                     |  9 +++++++--
 10 files changed, 60 insertions(+), 21 deletions(-)


base-commit: 9a2fb147f2c61d0cab52c883e7e26f5b7948e3ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2009%2Fdscho%2Fprepare-the-test-suite-for-symlink-support-on-windows-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2009/dscho/prepare-the-test-suite-for-symlink-support-on-windows-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2009

Range-diff vs v1:

  1:  2d329837e3 =  1:  2d329837e3 t9700: accommodate for Windows paths
  2:  b97afa9a5c =  2:  b97afa9a5c apply: symbolic links lack a "trustable executable bit"
  3:  96e279f50e =  3:  96e279f50e mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  4:  3be9594e80 !  4:  9639e04ac6 t0001: handle `diff --no-index` gracefully
     @@ Commit message
          file mode of 120000). That is totally unexpected by the test case, which
          as a consequence fails, meaning that it's a bug in the test case itself.
      
     +    Co-authored-by: Junio C Hamano <gitster@pobox.com>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
       ## t/t0001-init.sh ##
     @@ t/t0001-init.sh: test_expect_success SYMLINKS 're-init to move gitdir symlink' '
       	echo "gitdir: $(pwd)/realgitdir" >expected &&
      -	test_cmp expected newdir/.git &&
      +	case "$GIT_TEST_CMP" in
     -+	*--no-index*) ;; # git diff --no-index does not resolve symlinks
     ++	# `git diff --no-index` does not resolve symlinks
     ++	*--no-index*) cmp expected newdir/.git;;
      +	*) test_cmp expected newdir/.git;;
      +	esac &&
       	test_cmp expected newdir/here &&
  5:  c59a5f2478 =  5:  3db0599d91 t0301: another fix for Windows compatibility
  6:  0866db0a17 !  6:  f2da7d4d50 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:  8a7c68b629 =  7:  ea74e678f9 t1006: accommodate for symlink support in MSYS2
  8:  930828c693 =  8:  1619ea4a3b t1305: skip symlink tests that do not apply to Windows
  9:  b622ff822c =  9:  807bb679cd t6423: introduce Windows-specific handling for symlinking to /dev/null
 10:  f7f1e91cef ! 10:  945306b5d4 t7800: work around the MSYS path conversion on Windows
     @@ Commit message
      
          One instance of this problem can be observed in the 'difftool --dir-diff
          handles modified symlinks' test case in `t7800-difftool.sh`, which
     -    assumes that that all absolute paths start with a forward slash. That
     +    assumes that all absolute paths start with a forward slash. That
          assumption is incorrect in general, e.g. on Windows, where absolute
          paths have many shapes and forms, none of which starts with a forward
          slash.

-- 
gitgitgadget

[PATCH v2 01/10] t9700: accommodate for Windows paths

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Ever since fe53bbc9beb (Git.pm: Always set Repository to absolute path
if autodetecting, 2009-05-07), the t9700 test _must_ fail on Windows
because of that age-old Unix paths vs Windows paths problem.

The underlying root cause is that Git cannot run with a regular Win32
variant of Perl, the assumption that every path is a Unix path is just
too strong in Git's Perl code.

As a consequence, Git for Windows is basically stuck with using the
MSYS2 variant of Perl which uses a POSIX emulation layer (which is a
friendly fork of Cygwin) _and_ a best-effort Unix <-> Windows paths
conversion whenever crossing the boundary between MSYS2 and regular
Win32 processes. It is best effort only, though, using heuristics to
automagically convert correctly in most cases, but not in all cases.

In the context of this here patch, this means that asking `git.exe` for
the absolute path of the `.git/` directory will return a Win32 path
because `git.exe` is a regular Win32 executable that has no idea about
Unix-ish paths. But above-mentioned commit introduced a test that wants
to verify that this path is identical to the one that the Git Perl
module reports (which refuses to use Win32 paths and uses Unix-ish paths
instead). Obviously, this must fail because no heuristics can kick in at
that layer.

This test failure has not even been caught when Git introduced Windows
support in its CI definition in 2e90484eb4a (ci: add a Windows job to
the Azure Pipelines definition, 2019-01-29), as all tests relying on
Perl had to be disabled even from the start (because the CI runs would
otherwise have resulted in prohibitively long runtimes, not because
Windows is super slow per se, but because Git's test suite keeps
insisting on using technology that requires a POSIX emulation layer,
which _is_ super slow on Windows).

To work around this failure, let's use the `cygpath` utility to convert
the absolute `gitdir` path into the form that the Perl code expects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t9700/test.pl | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 58a9b328d5..570b0c5680 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -117,7 +117,12 @@ close TEMPFILE;
 unlink $tmpfile;
 
 # paths
-is($r->repo_path, $abs_repo_dir . "/.git", "repo_path");
+my $abs_git_dir = $abs_repo_dir . "/.git";
+if ($^O eq 'msys' or $^O eq 'cygwin') {
+  $abs_git_dir = `cygpath -am "$abs_repo_dir/.git"`;
+  $abs_git_dir =~ s/\r?\n?$//;
+}
+is($r->repo_path, $abs_git_dir, "repo_path");
 is($r->wc_path, $abs_repo_dir . "/", "wc_path");
 is($r->wc_subdir, "", "wc_subdir initial");
 $r->wc_chdir("directory1");
@@ -127,7 +132,7 @@ is($r->config("test.string"), "value", "config after wc_chdir");
 # Object generation in sub directory
 chdir("directory2");
 my $r2 = Git->repository();
-is($r2->repo_path, $abs_repo_dir . "/.git", "repo_path (2)");
+is($r2->repo_path, $abs_git_dir, "repo_path (2)");
 is($r2->wc_path, $abs_repo_dir . "/", "wc_path (2)");
 is($r2->wc_subdir, "directory2/", "wc_subdir initial (2)");
 
-- 
gitgitgadget

[PATCH v2 02/10] apply: symbolic links lack a "trustable executable bit"

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When 0482c32c334b (apply: ignore working tree filemode when
!core.filemode, 2023-12-26) fixed `git apply` to stop warning about
executable files, it inadvertently changed the code flow also for
symbolic links and directories.

Let's narrow the scope of the special `!trust_executable_git` code path
to apply only to regular files.

This is needed to let t4115.5(symlink escape when creating new files)
pass on Windows when symbolic link support is enabled in the MSYS2
runtime.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 apply.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apply.c b/apply.c
index a2ceb3fb40..de5750354a 100644
--- a/apply.c
+++ b/apply.c
@@ -3779,7 +3779,7 @@ static int check_preimage(struct apply_state *state,
 		if (*ce && !(*ce)->ce_mode)
 			BUG("ce_mode == 0 for path '%s'", old_name);
 
-		if (trust_executable_bit)
+		if (trust_executable_bit || !S_ISREG(st->st_mode))
 			st_mode = ce_mode_from_stat(*ce, st->st_mode);
 		else if (*ce)
 			st_mode = (*ce)->ce_mode;
-- 
gitgitgadget

[PATCH v2 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The `_wopen()` function would gladly follow a symbolic link to a
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.

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

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index 736a07a028..9fbf12a3d3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
 	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
 	wchar_t wfilename[MAX_PATH];
 	open_fn_t open_fn;
+	WIN32_FILE_ATTRIBUTE_DATA fdata;
 
 	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
 
@@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
 	else if (xutftowcs_path(wfilename, filename) < 0)
 		return -1;
 
+	/*
+	 * When `symlink` exists and is a symbolic link pointing to a
+	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
+	 * create that file. Not what we want: Linux would say `EEXIST`
+	 * in that instance, which is therefore what Git expects.
+	 */
+	if (create &&
+	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
+	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
+		errno = EEXIST;
+		return -1;
+	}
+
 	fd = open_fn(wfilename, oflags, mode);
 
 	/*
-- 
gitgitgadget

[PATCH v2 04/10] t0001: handle `diff --no-index` gracefully

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The test case 're-init to move gitdir symlink' wants to compare the
contents of `newdir/.git`, which is a symbolic link pointing to a file.
However, `git diff --no-index`, which is used by `test_cmp` on Windows,
does not resolve symlinks; It shows the symlink _target_ instead (with a
file mode of 120000). That is totally unexpected by the test case, which
as a consequence fails, meaning that it's a bug in the test case itself.

Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0001-init.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 618da080dc..e4d32bb4d2 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -425,7 +425,11 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
 	git init --separate-git-dir ../realgitdir
 	) &&
 	echo "gitdir: $(pwd)/realgitdir" >expected &&
-	test_cmp expected newdir/.git &&
+	case "$GIT_TEST_CMP" in
+	# `git diff --no-index` does not resolve symlinks
+	*--no-index*) cmp expected newdir/.git;;
+	*) test_cmp expected newdir/.git;;
+	esac &&
 	test_cmp expected newdir/here &&
 	test_path_is_dir realgitdir/refs
 '
-- 
gitgitgadget

[PATCH v2 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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

There was one forgotten instance of this which was hidden by a `SYMLINK`
prerequisite. Currently, this prevents this test case from being
executed on Windows, but with the upcoming support for symbolic links,
it would become a problem.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0301-credential-cache.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
index dc30289f75..6f7cfd9e33 100755
--- a/t/t0301-credential-cache.sh
+++ b/t/t0301-credential-cache.sh
@@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
 		rmdir \"\$HOME/dir/\" &&
 		rm \"\$HOME/.git-credential-cache\"
 	" &&
-	mkdir -p -m 700 "$HOME/dir/" &&
+	mkdir -p "$HOME/dir/" &&
+	chmod 700 "$HOME/dir/" &&
 	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
 	check approve cache <<-\EOF &&
 	protocol=https
-- 
gitgitgadget

[PATCH v2 06/10] t0600: fix incomplete prerequisite for a test case

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The 'symref transaction supports symlinks' test case is guarded by the
`SYMLINK` prerequisite because `core.prefersymlinkrefs = true` requires
symbolic links to be supported.

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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
index b11126ed47..74bfa2e9ba 100755
--- a/t/t0600-reffiles-backend.sh
+++ b/t/t0600-reffiles-backend.sh
@@ -467,7 +467,7 @@ test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
 	esac
 '
 
-test_expect_success SYMLINKS 'symref transaction supports symlinks' '
+test_expect_success SYMLINKS,!MINGW 'symref transaction supports symlinks' '
 	test_when_finished "git symbolic-ref -d TEST_SYMREF_HEAD" &&
 	git update-ref refs/heads/new @ &&
 	test_config core.prefersymlinkrefs true &&
-- 
gitgitgadget

[PATCH v2 07/10] t1006: accommodate for symlink support in MSYS2

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The MSYS2 runtime (which inherits this trait from the Cygwin runtime,
and which is used by Git for Windows' Bash to emulate POSIX
functionality on Windows, the same Bash that is also used to run Git's
test suite on Windows) has a mode where it can create native symbolic
links on Windows.

Naturally, this is a bit of a strange feature, given that Cygwin goes
out of its way to support Unix-like paths even if no Win32 program
understands those, and the symbolic links have to use Win32 paths
instead (which Win32 programs understand very well).

As a consequence, the symbolic link targets get normalized before the
links are created.

This results in certain quirks that Git's test suite is ill equipped to
accommodate (because Git's test suite expects to be able to use
Unix-like paths even on Windows).

The test script t1006-cat-file.sh contains two prime examples, two test
cases that need to skip a couple assertions because they are simply
wrong in the context of Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1006-cat-file.sh | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index 1f61b666a7..0eee3bb878 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -1048,18 +1048,28 @@ test_expect_success 'git cat-file --batch-check --follow-symlinks works for out-
 	echo .. >>expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual &&
-	echo symlink 3 >expect &&
-	echo ../ >>expect &&
+	if test_have_prereq MINGW,SYMLINKS
+	then
+		test_write_lines "symlink 2" ..
+	else
+		test_write_lines "symlink 3" ../
+	fi >expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir-trailing | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual
 '
 
 test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
-	echo HEAD: | git cat-file --batch-check >expect &&
-	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
-	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
+	if test_have_prereq !MINGW
+	then
+		# The `up-down` and `up-down-trailing` symlinks are normalized
+		# in MSYS in `winsymlinks` mode and are therefore in a
+		# different shape than Git expects them.
+		echo HEAD: | git cat-file --batch-check >expect &&
+		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual &&
+		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual
+	fi &&
 	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp found actual &&
 	echo symlink 7 >expect &&
-- 
gitgitgadget

[PATCH v2 08/10] t1305: skip symlink tests that do not apply to Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In Git for Windows, the gitdir is canonicalized so that even when the
gitdir is specified via a symbolic link, the `gitdir:` conditional
include will only match the real directory path.

Unfortunately, t1305 codifies a different behavior in two test cases,
which are hereby skipped on Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1305-config-include.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 8ff2b0c232..6e51f892f3 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -286,7 +286,7 @@ test_expect_success SYMLINKS 'conditional include, relative path with symlinks'
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink' '
 	ln -s foo bar &&
 	(
 		cd bar &&
@@ -298,7 +298,7 @@ test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink, icase' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink, icase' '
 	(
 		cd bar &&
 		echo "[includeIf \"gitdir/i:BAR/\"]path=bar8" >>.git/config &&
-- 
gitgitgadget

[PATCH v2 09/10] t6423: introduce Windows-specific handling for symlinking to /dev/null

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The device `/dev/null` does not exist on Windows, it's called `NUL`
there. Calling `ln -s /dev/null my-symlink` in a symlink-enabled MSYS2
Bash will therefore literally link to a file or directory called `null`
that is supposed to be in the current drive's top-level `dev` directory.
Which typically does not exist.

The test, however, really wants the created symbolic link to point to
the NUL device. Let's instead use the `mklink` utility on Windows to
perform that job, and keep using `ln -s /dev/null <target>` on
non-Windows platforms.

While at it, add the missing `SYMLINKS` prereq because this test _still_
would not pass on Windows before support for symbolic links is
upstreamed from Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t6423-merge-rename-directories.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
index 533ac85dc8..53535a8ebf 100755
--- a/t/t6423-merge-rename-directories.sh
+++ b/t/t6423-merge-rename-directories.sh
@@ -5158,13 +5158,18 @@ test_setup_12m () {
 		git switch B &&
 		git rm dir/subdir/file &&
 		mkdir dir &&
-		ln -s /dev/null dir/subdir &&
+		if test_have_prereq MINGW
+		then
+			cmd //c 'mklink dir\subdir NUL'
+		else
+			ln -s /dev/null dir/subdir
+		fi &&
 		git add . &&
 		git commit -m "B"
 	)
 }
 
-test_expect_success '12m: Change parent of renamed-dir to symlink on other side' '
+test_expect_success SYMLINKS '12m: Change parent of renamed-dir to symlink on other side' '
 	test_setup_12m &&
 	(
 		cd 12m &&
-- 
gitgitgadget

[PATCH v2 10/10] t7800: work around the MSYS path conversion on Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git's test suite's relies on Unix shell scripting, which is
understandable, of course, given Git's firm roots (and indeed, ongoing
focus) on Linux.

This fact, combined with Unix shell scripting's natural
habitat -- which is, naturally... *drumroll*... Unix --
often has unintended side effects, where developers expect the test
suite to run in a Unix environment, which is an incorrect assumption.

One instance of this problem can be observed in the 'difftool --dir-diff
handles modified symlinks' test case in `t7800-difftool.sh`, which
assumes that all absolute paths start with a forward slash. That
assumption is incorrect in general, e.g. on Windows, where absolute
paths have many shapes and forms, none of which starts with a forward
slash.

The only saving grace is that this test case is currently not run on
Windows because of the `SYMLINK` prerequisite. However, I am currently
working towards upstreaming symbolic link support from Git for Windows
to upstream Git, which will put a crack into that saving grace.

Let's change that test case so that it does not rely on absolute paths
(which are passed to the "external command" `ls` as parameters and are
therefore part of its output, and which the test case wants to filter
out before verifying that the output is as expected) starting with a
forward slash. Let's instead rely on the much more reliable fact that
`ls` will output the path in a line that ends in a colon, and simply
filter out those lines by matching said colon instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7800-difftool.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 9b74db5563..bf0f67378d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -752,11 +752,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 		c
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	# The left side contains symlink "c" that points to "b"
@@ -786,11 +786,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual
 '
 
-- 
gitgitgadget

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

[Patrick Steinhardt]

On Fri, Dec 05, 2025 at 03:02:15PM +0000, Johannes Schindelin via GitGitGadget wrote:
> Changes since v1:
> 
>  * Fixed a grammar issue.
>  * Using cmp rather than skipping the comparison (thanks Junio).
>  * Extended a commit message to explain that it covers all the cases where
>    core.preferSymlinkRefs needs special care.

Thanks, the range-diff looks good to me!

Patrick

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

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Fri, Dec 05, 2025 at 03:02:15PM +0000, Johannes Schindelin via GitGitGadget wrote:
>> Changes since v1:
>> 
>>  * Fixed a grammar issue.
>>  * Using cmp rather than skipping the comparison (thanks Junio).
>>  * Extended a commit message to explain that it covers all the cases where
>>    core.preferSymlinkRefs needs special care.
>
> Thanks, the range-diff looks good to me!
>
> Patrick

Thanks, both.  Queued.

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

[Johannes Schindelin via GitGitGadget]

Git for Windows has supported symbolic links for quite some time: In
https://github.com/git-for-windows/git/pull/156, this support was introduced
already into Git for Windows v2.4.2.windows.1 in May 2015.

However, the Git for Windows CI never ran the test suite with symbolic link
support because the MSYS2 runtime (i.e. the POSIX emulation layer required
to run Git's test suite because the latter is written in Unix shell script)
does not support symbolic links right out of the box. This is for historical
reasons: Symbolic link support was introduced in Windows 7, where these
links could only be created by administrators by default, and it took until
Windows 10 Build 14972 that at least in Developer Mode, non-administrators
would be permitted to create them.

The MSYS2 runtime does have some sort of support for symbolic links,
although with caveats: seeing as it expects the inputs as Unix-like paths,
but the outputs need to be Win32 symbolic links pointing to Win32 paths,
some normalization has to be performed in the process. This leads to
sometimes surprising behavior e.g. when a link target like a/b/.. is
normalized to a.

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

Changes since v2:

 * Polished commit messages.
 * 

Changes since v1:

 * Fixed a grammar issue.
 * Using cmp rather than skipping the comparison (thanks Junio).
 * Extended a commit message to explain that it covers all the cases where
   core.preferSymlinkRefs needs special care.

Johannes Schindelin (10):
  t9700: accommodate for Windows paths
  apply: symbolic links lack a "trustable executable bit"
  mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  t0001: handle `diff --no-index` gracefully
  t0301: another fix for Windows compatibility
  t0600: fix incomplete prerequisite for a test case
  t1006: accommodate for symlink support in MSYS2
  t1305: skip symlink tests that do not apply to Windows
  t6423: introduce Windows-specific handling for symlinking to /dev/null
  t7800: work around the MSYS path conversion on Windows

 apply.c                             |  2 +-
 compat/mingw.c                      | 14 ++++++++++++++
 t/t0001-init.sh                     |  6 +++++-
 t/t0301-credential-cache.sh         |  3 ++-
 t/t0600-reffiles-backend.sh         |  2 +-
 t/t1006-cat-file.sh                 | 24 +++++++++++++++++-------
 t/t1305-config-include.sh           |  4 ++--
 t/t6423-merge-rename-directories.sh |  9 +++++++--
 t/t7800-difftool.sh                 |  8 ++++----
 t/t9700/test.pl                     |  9 +++++++--
 10 files changed, 60 insertions(+), 21 deletions(-)


base-commit: 9a2fb147f2c61d0cab52c883e7e26f5b7948e3ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2009%2Fdscho%2Fprepare-the-test-suite-for-symlink-support-on-windows-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2009/dscho/prepare-the-test-suite-for-symlink-support-on-windows-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/2009

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

-- 
gitgitgadget

[PATCH v3 01/10] t9700: accommodate for Windows paths

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Ever since fe53bbc9beb (Git.pm: Always set Repository to absolute path
if autodetecting, 2009-05-07), the t9700 test _must_ fail on Windows
because of that age-old Unix paths vs Windows paths problem.

The underlying root cause is that Git cannot run with a regular Win32
variant of Perl, the assumption that every path is a Unix path is just
too strong in Git's Perl code.

As a consequence, Git for Windows is basically stuck with using the
MSYS2 variant of Perl which uses a POSIX emulation layer (which is a
friendly fork of Cygwin) _and_ a best-effort Unix <-> Windows paths
conversion whenever crossing the boundary between MSYS2 and regular
Win32 processes. It is best effort only, though, using heuristics to
automagically convert correctly in most cases, but not in all cases.

In the context of this here patch, this means that asking `git.exe` for
the absolute path of the `.git/` directory will return a Win32 path
because `git.exe` is a regular Win32 executable that has no idea about
Unix-ish paths. But above-mentioned commit introduced a test that wants
to verify that this path is identical to the one that the Git Perl
module reports (which refuses to use Win32 paths and uses Unix-ish paths
instead). Obviously, this must fail because no heuristics can kick in at
that layer.

This test failure has not even been caught when Git introduced Windows
support in its CI definition in 2e90484eb4a (ci: add a Windows job to
the Azure Pipelines definition, 2019-01-29), as all tests relying on
Perl had to be disabled even from the start (because the CI runs would
otherwise have resulted in prohibitively long runtimes, not because
Windows is super slow per se, but because Git's test suite keeps
insisting on using technology that requires a POSIX emulation layer,
which _is_ super slow on Windows).

To work around this failure, let's use the `cygpath` utility to convert
the absolute `gitdir` path into the form that the Perl code expects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t9700/test.pl | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 58a9b328d5..570b0c5680 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -117,7 +117,12 @@ close TEMPFILE;
 unlink $tmpfile;
 
 # paths
-is($r->repo_path, $abs_repo_dir . "/.git", "repo_path");
+my $abs_git_dir = $abs_repo_dir . "/.git";
+if ($^O eq 'msys' or $^O eq 'cygwin') {
+  $abs_git_dir = `cygpath -am "$abs_repo_dir/.git"`;
+  $abs_git_dir =~ s/\r?\n?$//;
+}
+is($r->repo_path, $abs_git_dir, "repo_path");
 is($r->wc_path, $abs_repo_dir . "/", "wc_path");
 is($r->wc_subdir, "", "wc_subdir initial");
 $r->wc_chdir("directory1");
@@ -127,7 +132,7 @@ is($r->config("test.string"), "value", "config after wc_chdir");
 # Object generation in sub directory
 chdir("directory2");
 my $r2 = Git->repository();
-is($r2->repo_path, $abs_repo_dir . "/.git", "repo_path (2)");
+is($r2->repo_path, $abs_git_dir, "repo_path (2)");
 is($r2->wc_path, $abs_repo_dir . "/", "wc_path (2)");
 is($r2->wc_subdir, "directory2/", "wc_subdir initial (2)");
 
-- 
gitgitgadget

[PATCH v3 02/10] apply: symbolic links lack a "trustable executable bit"

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When 0482c32c334b (apply: ignore working tree filemode when
!core.filemode, 2023-12-26) fixed `git apply` to stop warning about
executable files, it inadvertently changed the code flow also for
symbolic links and directories.

Let's narrow the scope of the special `!trust_executable_git` code path
to apply only to regular files.

This is needed to let t4115.5(symlink escape when creating new files)
pass on Windows when symbolic link support is enabled in the MSYS2
runtime.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 apply.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apply.c b/apply.c
index a2ceb3fb40..de5750354a 100644
--- a/apply.c
+++ b/apply.c
@@ -3779,7 +3779,7 @@ static int check_preimage(struct apply_state *state,
 		if (*ce && !(*ce)->ce_mode)
 			BUG("ce_mode == 0 for path '%s'", old_name);
 
-		if (trust_executable_bit)
+		if (trust_executable_bit || !S_ISREG(st->st_mode))
 			st_mode = ce_mode_from_stat(*ce, st->st_mode);
 		else if (*ce)
 			st_mode = (*ce)->ce_mode;
-- 
gitgitgadget

[PATCH v3 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The `_wopen()` function would gladly follow a symbolic link to a
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 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
support.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index 736a07a028..9fbf12a3d3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
 	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
 	wchar_t wfilename[MAX_PATH];
 	open_fn_t open_fn;
+	WIN32_FILE_ATTRIBUTE_DATA fdata;
 
 	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
 
@@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
 	else if (xutftowcs_path(wfilename, filename) < 0)
 		return -1;
 
+	/*
+	 * When `symlink` exists and is a symbolic link pointing to a
+	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
+	 * create that file. Not what we want: Linux would say `EEXIST`
+	 * in that instance, which is therefore what Git expects.
+	 */
+	if (create &&
+	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
+	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
+		errno = EEXIST;
+		return -1;
+	}
+
 	fd = open_fn(wfilename, oflags, mode);
 
 	/*
-- 
gitgitgadget

[PATCH v3 04/10] t0001: handle `diff --no-index` gracefully

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The test case 're-init to move gitdir symlink' wants to compare the
contents of `newdir/.git`, which is a symbolic link pointing to a file.
However, `git diff --no-index`, which is used by `test_cmp` on Windows,
does not resolve symlinks; It shows the symlink _target_ instead (with a
file mode of 120000). That is totally unexpected by the test case, which
as a consequence fails, meaning that it's a bug in the test case itself.

Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0001-init.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 618da080dc..e4d32bb4d2 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -425,7 +425,11 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
 	git init --separate-git-dir ../realgitdir
 	) &&
 	echo "gitdir: $(pwd)/realgitdir" >expected &&
-	test_cmp expected newdir/.git &&
+	case "$GIT_TEST_CMP" in
+	# `git diff --no-index` does not resolve symlinks
+	*--no-index*) cmp expected newdir/.git;;
+	*) test_cmp expected newdir/.git;;
+	esac &&
 	test_cmp expected newdir/here &&
 	test_path_is_dir realgitdir/refs
 '
-- 
gitgitgadget

[PATCH v3 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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.

There was one forgotten instance of this which was hidden by a `SYMLINK`
prerequisite. Currently, this prevents this test case from being
executed on Windows, but with the upcoming support for symbolic links,
it would become a problem.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0301-credential-cache.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
index dc30289f75..6f7cfd9e33 100755
--- a/t/t0301-credential-cache.sh
+++ b/t/t0301-credential-cache.sh
@@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
 		rmdir \"\$HOME/dir/\" &&
 		rm \"\$HOME/.git-credential-cache\"
 	" &&
-	mkdir -p -m 700 "$HOME/dir/" &&
+	mkdir -p "$HOME/dir/" &&
+	chmod 700 "$HOME/dir/" &&
 	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
 	check approve cache <<-\EOF &&
 	protocol=https
-- 
gitgitgadget

[PATCH v3 07/10] t1006: accommodate for symlink support in MSYS2

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The MSYS2 runtime (which inherits this trait from the Cygwin runtime,
and which is used by Git for Windows' Bash to emulate POSIX
functionality on Windows, the same Bash that is also used to run Git's
test suite on Windows) has a mode where it can create native symbolic
links on Windows.

Naturally, this is a bit of a strange feature, given that Cygwin goes
out of its way to support Unix-like paths even if no Win32 program
understands those, and the symbolic links have to use Win32 paths
instead (which Win32 programs understand very well).

As a consequence, the symbolic link targets get normalized before the
links are created.

This results in certain quirks that Git's test suite is ill equipped to
accommodate (because Git's test suite expects to be able to use
Unix-like paths even on Windows).

The test script t1006-cat-file.sh contains two prime examples, two test
cases that need to skip a couple assertions because they are simply
wrong in the context of Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1006-cat-file.sh | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index 1f61b666a7..0eee3bb878 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -1048,18 +1048,28 @@ test_expect_success 'git cat-file --batch-check --follow-symlinks works for out-
 	echo .. >>expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual &&
-	echo symlink 3 >expect &&
-	echo ../ >>expect &&
+	if test_have_prereq MINGW,SYMLINKS
+	then
+		test_write_lines "symlink 2" ..
+	else
+		test_write_lines "symlink 3" ../
+	fi >expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir-trailing | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual
 '
 
 test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
-	echo HEAD: | git cat-file --batch-check >expect &&
-	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
-	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
+	if test_have_prereq !MINGW
+	then
+		# The `up-down` and `up-down-trailing` symlinks are normalized
+		# in MSYS in `winsymlinks` mode and are therefore in a
+		# different shape than Git expects them.
+		echo HEAD: | git cat-file --batch-check >expect &&
+		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual &&
+		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual
+	fi &&
 	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp found actual &&
 	echo symlink 7 >expect &&
-- 
gitgitgadget

[PATCH v3 08/10] t1305: skip symlink tests that do not apply to Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In Git for Windows, the gitdir is canonicalized so that even when the
gitdir is specified via a symbolic link, the `gitdir:` conditional
include will only match the real directory path.

Unfortunately, t1305 codifies a different behavior in two test cases,
which are hereby skipped on Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1305-config-include.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 8ff2b0c232..6e51f892f3 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -286,7 +286,7 @@ test_expect_success SYMLINKS 'conditional include, relative path with symlinks'
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink' '
 	ln -s foo bar &&
 	(
 		cd bar &&
@@ -298,7 +298,7 @@ test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink, icase' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink, icase' '
 	(
 		cd bar &&
 		echo "[includeIf \"gitdir/i:BAR/\"]path=bar8" >>.git/config &&
-- 
gitgitgadget

[PATCH v3 09/10] t6423: introduce Windows-specific handling for symlinking to /dev/null

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The device `/dev/null` does not exist on Windows, it's called `NUL`
there. Calling `ln -s /dev/null my-symlink` in a symlink-enabled MSYS2
Bash will therefore literally link to a file or directory called `null`
that is supposed to be in the current drive's top-level `dev` directory.
Which typically does not exist.

The test, however, really wants the created symbolic link to point to
the NUL device. Let's instead use the `mklink` utility on Windows to
perform that job, and keep using `ln -s /dev/null <target>` on
non-Windows platforms.

While at it, add the missing `SYMLINKS` prereq because this test _still_
would not pass on Windows before support for symbolic links is
upstreamed from Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t6423-merge-rename-directories.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
index 533ac85dc8..53535a8ebf 100755
--- a/t/t6423-merge-rename-directories.sh
+++ b/t/t6423-merge-rename-directories.sh
@@ -5158,13 +5158,18 @@ test_setup_12m () {
 		git switch B &&
 		git rm dir/subdir/file &&
 		mkdir dir &&
-		ln -s /dev/null dir/subdir &&
+		if test_have_prereq MINGW
+		then
+			cmd //c 'mklink dir\subdir NUL'
+		else
+			ln -s /dev/null dir/subdir
+		fi &&
 		git add . &&
 		git commit -m "B"
 	)
 }
 
-test_expect_success '12m: Change parent of renamed-dir to symlink on other side' '
+test_expect_success SYMLINKS '12m: Change parent of renamed-dir to symlink on other side' '
 	test_setup_12m &&
 	(
 		cd 12m &&
-- 
gitgitgadget

[PATCH v3 10/10] t7800: work around the MSYS path conversion on Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git's test suite's relies on Unix shell scripting, which is
understandable, of course, given Git's firm roots (and indeed, ongoing
focus) on Linux.

This fact, combined with Unix shell scripting's natural
habitat -- which is, naturally... *drumroll*... Unix --
often has unintended side effects, where developers expect the test
suite to run in a Unix environment, which is an incorrect assumption.

One instance of this problem can be observed in the 'difftool --dir-diff
handles modified symlinks' test case in `t7800-difftool.sh`, which
assumes that all absolute paths start with a forward slash. That
assumption is incorrect in general, e.g. on Windows, where absolute
paths have many shapes and forms, none of which starts with a forward
slash.

The only saving grace is that this test case is currently not run on
Windows because of the `SYMLINK` prerequisite. However, I am currently
working towards upstreaming symbolic link support from Git for Windows
to upstream Git, which will put a crack into that saving grace.

Let's change that test case so that it does not rely on absolute paths
(which are passed to the "external command" `ls` as parameters and are
therefore part of its output, and which the test case wants to filter
out before verifying that the output is as expected) starting with a
forward slash. Let's instead rely on the much more reliable fact that
`ls` will output the path in a line that ends in a colon, and simply
filter out those lines by matching said colon instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7800-difftool.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 9b74db5563..bf0f67378d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -752,11 +752,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 		c
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	# The left side contains symlink "c" that points to "b"
@@ -786,11 +786,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual
 '
 
-- 
gitgitgadget

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

[Junio C Hamano]

"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

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

[Johannes Schindelin]

Hi Junio,

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

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

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

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

[Junio C Hamano]

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

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

OK.  If I am reading you correctly, fetching from the v3 pull
request tag would not solve the breakage in [06/10], right?

re there similar "oops, I meant to change this and that but the
resulting tree did not get any of them" for steps [07-10/10], which
did not see any changes in the messages on the list?  Presumably, it
would not help these steps if I fetching from the v3 pull request
tag, either, right?

Thanks.

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

[Johannes Schindelin via GitGitGadget]

Git for Windows has supported symbolic links for quite some time: In
https://github.com/git-for-windows/git/pull/156, this support was introduced
already into Git for Windows v2.4.2.windows.1 in May 2015.

However, the Git for Windows CI never ran the test suite with symbolic link
support because the MSYS2 runtime (i.e. the POSIX emulation layer required
to run Git's test suite because the latter is written in Unix shell script)
does not support symbolic links right out of the box. This is for historical
reasons: Symbolic link support was introduced in Windows 7, where these
links could only be created by administrators by default, and it took until
Windows 10 Build 14972 that at least in Developer Mode, non-administrators
would be permitted to create them.

The MSYS2 runtime does have some sort of support for symbolic links,
although with caveats: seeing as it expects the inputs as Unix-like paths,
but the outputs need to be Win32 symbolic links pointing to Win32 paths,
some normalization has to be performed in the process. This leads to
sometimes surprising behavior e.g. when a link target like a/b/.. is
normalized to a.

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

Changes since v3:

 * Re-added the credits to Patrick's research that was accidentally dropped
   from the commit message of "t0600: fix incomplete prerequisite for a test
   case"

Changes since v2:

 * Polished commit messages.

Changes since v1:

 * Fixed a grammar issue.
 * Using cmp rather than skipping the comparison (thanks Junio).
 * Extended a commit message to explain that it covers all the cases where
   core.preferSymlinkRefs needs special care.

Johannes Schindelin (10):
  t9700: accommodate for Windows paths
  apply: symbolic links lack a "trustable executable bit"
  mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  t0001: handle `diff --no-index` gracefully
  t0301: another fix for Windows compatibility
  t0600: fix incomplete prerequisite for a test case
  t1006: accommodate for symlink support in MSYS2
  t1305: skip symlink tests that do not apply to Windows
  t6423: introduce Windows-specific handling for symlinking to /dev/null
  t7800: work around the MSYS path conversion on Windows

 apply.c                             |  2 +-
 compat/mingw.c                      | 14 ++++++++++++++
 t/t0001-init.sh                     |  6 +++++-
 t/t0301-credential-cache.sh         |  3 ++-
 t/t0600-reffiles-backend.sh         |  2 +-
 t/t1006-cat-file.sh                 | 24 +++++++++++++++++-------
 t/t1305-config-include.sh           |  4 ++--
 t/t6423-merge-rename-directories.sh |  9 +++++++--
 t/t7800-difftool.sh                 |  8 ++++----
 t/t9700/test.pl                     |  9 +++++++--
 10 files changed, 60 insertions(+), 21 deletions(-)


base-commit: 9a2fb147f2c61d0cab52c883e7e26f5b7948e3ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2009%2Fdscho%2Fprepare-the-test-suite-for-symlink-support-on-windows-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2009/dscho/prepare-the-test-suite-for-symlink-support-on-windows-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/2009

Range-diff vs v3:

  1:  2d329837e3 =  1:  2d329837e3 t9700: accommodate for Windows paths
  2:  b97afa9a5c =  2:  b97afa9a5c apply: symbolic links lack a "trustable executable bit"
  3:  f42a2f14bc =  3:  f42a2f14bc mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
  4:  70237394c6 =  4:  70237394c6 t0001: handle `diff --no-index` gracefully
  5:  0d371ee552 =  5:  0d371ee552 t0301: another fix for Windows compatibility
  6:  91bd72062c !  6:  7b233c2d40 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:  c2d3212f11 =  7:  31ed59481c t1006: accommodate for symlink support in MSYS2
  8:  03ff6d756d =  8:  37f9614ef5 t1305: skip symlink tests that do not apply to Windows
  9:  4ab6aaf2cf =  9:  e604ace822 t6423: introduce Windows-specific handling for symlinking to /dev/null
 10:  5f056902df = 10:  6caf8bf0b1 t7800: work around the MSYS path conversion on Windows

-- 
gitgitgadget

[PATCH v4 01/10] t9700: accommodate for Windows paths

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Ever since fe53bbc9beb (Git.pm: Always set Repository to absolute path
if autodetecting, 2009-05-07), the t9700 test _must_ fail on Windows
because of that age-old Unix paths vs Windows paths problem.

The underlying root cause is that Git cannot run with a regular Win32
variant of Perl, the assumption that every path is a Unix path is just
too strong in Git's Perl code.

As a consequence, Git for Windows is basically stuck with using the
MSYS2 variant of Perl which uses a POSIX emulation layer (which is a
friendly fork of Cygwin) _and_ a best-effort Unix <-> Windows paths
conversion whenever crossing the boundary between MSYS2 and regular
Win32 processes. It is best effort only, though, using heuristics to
automagically convert correctly in most cases, but not in all cases.

In the context of this here patch, this means that asking `git.exe` for
the absolute path of the `.git/` directory will return a Win32 path
because `git.exe` is a regular Win32 executable that has no idea about
Unix-ish paths. But above-mentioned commit introduced a test that wants
to verify that this path is identical to the one that the Git Perl
module reports (which refuses to use Win32 paths and uses Unix-ish paths
instead). Obviously, this must fail because no heuristics can kick in at
that layer.

This test failure has not even been caught when Git introduced Windows
support in its CI definition in 2e90484eb4a (ci: add a Windows job to
the Azure Pipelines definition, 2019-01-29), as all tests relying on
Perl had to be disabled even from the start (because the CI runs would
otherwise have resulted in prohibitively long runtimes, not because
Windows is super slow per se, but because Git's test suite keeps
insisting on using technology that requires a POSIX emulation layer,
which _is_ super slow on Windows).

To work around this failure, let's use the `cygpath` utility to convert
the absolute `gitdir` path into the form that the Perl code expects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t9700/test.pl | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 58a9b328d5..570b0c5680 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -117,7 +117,12 @@ close TEMPFILE;
 unlink $tmpfile;
 
 # paths
-is($r->repo_path, $abs_repo_dir . "/.git", "repo_path");
+my $abs_git_dir = $abs_repo_dir . "/.git";
+if ($^O eq 'msys' or $^O eq 'cygwin') {
+  $abs_git_dir = `cygpath -am "$abs_repo_dir/.git"`;
+  $abs_git_dir =~ s/\r?\n?$//;
+}
+is($r->repo_path, $abs_git_dir, "repo_path");
 is($r->wc_path, $abs_repo_dir . "/", "wc_path");
 is($r->wc_subdir, "", "wc_subdir initial");
 $r->wc_chdir("directory1");
@@ -127,7 +132,7 @@ is($r->config("test.string"), "value", "config after wc_chdir");
 # Object generation in sub directory
 chdir("directory2");
 my $r2 = Git->repository();
-is($r2->repo_path, $abs_repo_dir . "/.git", "repo_path (2)");
+is($r2->repo_path, $abs_git_dir, "repo_path (2)");
 is($r2->wc_path, $abs_repo_dir . "/", "wc_path (2)");
 is($r2->wc_subdir, "directory2/", "wc_subdir initial (2)");
 
-- 
gitgitgadget

[PATCH v4 02/10] apply: symbolic links lack a "trustable executable bit"

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When 0482c32c334b (apply: ignore working tree filemode when
!core.filemode, 2023-12-26) fixed `git apply` to stop warning about
executable files, it inadvertently changed the code flow also for
symbolic links and directories.

Let's narrow the scope of the special `!trust_executable_git` code path
to apply only to regular files.

This is needed to let t4115.5(symlink escape when creating new files)
pass on Windows when symbolic link support is enabled in the MSYS2
runtime.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 apply.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/apply.c b/apply.c
index a2ceb3fb40..de5750354a 100644
--- a/apply.c
+++ b/apply.c
@@ -3779,7 +3779,7 @@ static int check_preimage(struct apply_state *state,
 		if (*ce && !(*ce)->ce_mode)
 			BUG("ce_mode == 0 for path '%s'", old_name);
 
-		if (trust_executable_bit)
+		if (trust_executable_bit || !S_ISREG(st->st_mode))
 			st_mode = ce_mode_from_stat(*ce, st->st_mode);
 		else if (*ce)
 			st_mode = (*ce)->ce_mode;
-- 
gitgitgadget

[PATCH v4 03/10] mingw: special-case `open(symlink, O_CREAT | O_EXCL)`

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The `_wopen()` function would gladly follow a symbolic link to a
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 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
support.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index 736a07a028..9fbf12a3d3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -627,6 +627,7 @@ int mingw_open (const char *filename, int oflags, ...)
 	int fd, create = (oflags & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
 	wchar_t wfilename[MAX_PATH];
 	open_fn_t open_fn;
+	WIN32_FILE_ATTRIBUTE_DATA fdata;
 
 	DECLARE_PROC_ADDR(ntdll.dll, NTSTATUS, NTAPI, RtlGetLastNtStatus, void);
 
@@ -651,6 +652,19 @@ int mingw_open (const char *filename, int oflags, ...)
 	else if (xutftowcs_path(wfilename, filename) < 0)
 		return -1;
 
+	/*
+	 * When `symlink` exists and is a symbolic link pointing to a
+	 * non-existing file, `_wopen(symlink, O_CREAT | O_EXCL)` would
+	 * create that file. Not what we want: Linux would say `EEXIST`
+	 * in that instance, which is therefore what Git expects.
+	 */
+	if (create &&
+	    GetFileAttributesExW(wfilename, GetFileExInfoStandard, &fdata) &&
+	    (fdata.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)) {
+		errno = EEXIST;
+		return -1;
+	}
+
 	fd = open_fn(wfilename, oflags, mode);
 
 	/*
-- 
gitgitgadget

[PATCH v4 04/10] t0001: handle `diff --no-index` gracefully

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The test case 're-init to move gitdir symlink' wants to compare the
contents of `newdir/.git`, which is a symbolic link pointing to a file.
However, `git diff --no-index`, which is used by `test_cmp` on Windows,
does not resolve symlinks; It shows the symlink _target_ instead (with a
file mode of 120000). That is totally unexpected by the test case, which
as a consequence fails, meaning that it's a bug in the test case itself.

Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0001-init.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 618da080dc..e4d32bb4d2 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -425,7 +425,11 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' '
 	git init --separate-git-dir ../realgitdir
 	) &&
 	echo "gitdir: $(pwd)/realgitdir" >expected &&
-	test_cmp expected newdir/.git &&
+	case "$GIT_TEST_CMP" in
+	# `git diff --no-index` does not resolve symlinks
+	*--no-index*) cmp expected newdir/.git;;
+	*) test_cmp expected newdir/.git;;
+	esac &&
 	test_cmp expected newdir/here &&
 	test_path_is_dir realgitdir/refs
 '
-- 
gitgitgadget

[PATCH v4 05/10] t0301: another fix for Windows compatibility

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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.

There was one forgotten instance of this which was hidden by a `SYMLINK`
prerequisite. Currently, this prevents this test case from being
executed on Windows, but with the upcoming support for symbolic links,
it would become a problem.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t0301-credential-cache.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
index dc30289f75..6f7cfd9e33 100755
--- a/t/t0301-credential-cache.sh
+++ b/t/t0301-credential-cache.sh
@@ -123,7 +123,8 @@ test_expect_success SYMLINKS 'use user socket if user directory is a symlink to
 		rmdir \"\$HOME/dir/\" &&
 		rm \"\$HOME/.git-credential-cache\"
 	" &&
-	mkdir -p -m 700 "$HOME/dir/" &&
+	mkdir -p "$HOME/dir/" &&
+	chmod 700 "$HOME/dir/" &&
 	ln -s "$HOME/dir" "$HOME/.git-credential-cache" &&
 	check approve cache <<-\EOF &&
 	protocol=https
-- 
gitgitgadget

[PATCH v4 06/10] t0600: fix incomplete prerequisite for a test case

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The 'symref transaction supports symlinks' test case is guarded by the
`SYMLINK` prerequisite because `core.prefersymlinkrefs = true` requires
symbolic links to be supported.

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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
index b11126ed47..74bfa2e9ba 100755
--- a/t/t0600-reffiles-backend.sh
+++ b/t/t0600-reffiles-backend.sh
@@ -467,7 +467,7 @@ test_expect_success POSIXPERM 'git reflog expire honors core.sharedRepository' '
 	esac
 '
 
-test_expect_success SYMLINKS 'symref transaction supports symlinks' '
+test_expect_success SYMLINKS,!MINGW 'symref transaction supports symlinks' '
 	test_when_finished "git symbolic-ref -d TEST_SYMREF_HEAD" &&
 	git update-ref refs/heads/new @ &&
 	test_config core.prefersymlinkrefs true &&
-- 
gitgitgadget

[PATCH v4 07/10] t1006: accommodate for symlink support in MSYS2

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The MSYS2 runtime (which inherits this trait from the Cygwin runtime,
and which is used by Git for Windows' Bash to emulate POSIX
functionality on Windows, the same Bash that is also used to run Git's
test suite on Windows) has a mode where it can create native symbolic
links on Windows.

Naturally, this is a bit of a strange feature, given that Cygwin goes
out of its way to support Unix-like paths even if no Win32 program
understands those, and the symbolic links have to use Win32 paths
instead (which Win32 programs understand very well).

As a consequence, the symbolic link targets get normalized before the
links are created.

This results in certain quirks that Git's test suite is ill equipped to
accommodate (because Git's test suite expects to be able to use
Unix-like paths even on Windows).

The test script t1006-cat-file.sh contains two prime examples, two test
cases that need to skip a couple assertions because they are simply
wrong in the context of Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1006-cat-file.sh | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index 1f61b666a7..0eee3bb878 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -1048,18 +1048,28 @@ test_expect_success 'git cat-file --batch-check --follow-symlinks works for out-
 	echo .. >>expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual &&
-	echo symlink 3 >expect &&
-	echo ../ >>expect &&
+	if test_have_prereq MINGW,SYMLINKS
+	then
+		test_write_lines "symlink 2" ..
+	else
+		test_write_lines "symlink 3" ../
+	fi >expect &&
 	echo HEAD:dir/subdir/out-of-repo-link-dir-trailing | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp expect actual
 '
 
 test_expect_success 'git cat-file --batch-check --follow-symlinks works for symlinks with internal ..' '
-	echo HEAD: | git cat-file --batch-check >expect &&
-	echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
-	echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
-	test_cmp expect actual &&
+	if test_have_prereq !MINGW
+	then
+		# The `up-down` and `up-down-trailing` symlinks are normalized
+		# in MSYS in `winsymlinks` mode and are therefore in a
+		# different shape than Git expects them.
+		echo HEAD: | git cat-file --batch-check >expect &&
+		echo HEAD:up-down | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual &&
+		echo HEAD:up-down-trailing | git cat-file --batch-check --follow-symlinks >actual &&
+		test_cmp expect actual
+	fi &&
 	echo HEAD:up-down-file | git cat-file --batch-check --follow-symlinks >actual &&
 	test_cmp found actual &&
 	echo symlink 7 >expect &&
-- 
gitgitgadget

[PATCH v4 08/10] t1305: skip symlink tests that do not apply to Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In Git for Windows, the gitdir is canonicalized so that even when the
gitdir is specified via a symbolic link, the `gitdir:` conditional
include will only match the real directory path.

Unfortunately, t1305 codifies a different behavior in two test cases,
which are hereby skipped on Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1305-config-include.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index 8ff2b0c232..6e51f892f3 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -286,7 +286,7 @@ test_expect_success SYMLINKS 'conditional include, relative path with symlinks'
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink' '
 	ln -s foo bar &&
 	(
 		cd bar &&
@@ -298,7 +298,7 @@ test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
 	)
 '
 
-test_expect_success SYMLINKS 'conditional include, gitdir matching symlink, icase' '
+test_expect_success SYMLINKS,!MINGW 'conditional include, gitdir matching symlink, icase' '
 	(
 		cd bar &&
 		echo "[includeIf \"gitdir/i:BAR/\"]path=bar8" >>.git/config &&
-- 
gitgitgadget

[PATCH v4 09/10] t6423: introduce Windows-specific handling for symlinking to /dev/null

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The device `/dev/null` does not exist on Windows, it's called `NUL`
there. Calling `ln -s /dev/null my-symlink` in a symlink-enabled MSYS2
Bash will therefore literally link to a file or directory called `null`
that is supposed to be in the current drive's top-level `dev` directory.
Which typically does not exist.

The test, however, really wants the created symbolic link to point to
the NUL device. Let's instead use the `mklink` utility on Windows to
perform that job, and keep using `ln -s /dev/null <target>` on
non-Windows platforms.

While at it, add the missing `SYMLINKS` prereq because this test _still_
would not pass on Windows before support for symbolic links is
upstreamed from Git for Windows.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t6423-merge-rename-directories.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
index 533ac85dc8..53535a8ebf 100755
--- a/t/t6423-merge-rename-directories.sh
+++ b/t/t6423-merge-rename-directories.sh
@@ -5158,13 +5158,18 @@ test_setup_12m () {
 		git switch B &&
 		git rm dir/subdir/file &&
 		mkdir dir &&
-		ln -s /dev/null dir/subdir &&
+		if test_have_prereq MINGW
+		then
+			cmd //c 'mklink dir\subdir NUL'
+		else
+			ln -s /dev/null dir/subdir
+		fi &&
 		git add . &&
 		git commit -m "B"
 	)
 }
 
-test_expect_success '12m: Change parent of renamed-dir to symlink on other side' '
+test_expect_success SYMLINKS '12m: Change parent of renamed-dir to symlink on other side' '
 	test_setup_12m &&
 	(
 		cd 12m &&
-- 
gitgitgadget

[PATCH v4 10/10] t7800: work around the MSYS path conversion on Windows

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Git's test suite's relies on Unix shell scripting, which is
understandable, of course, given Git's firm roots (and indeed, ongoing
focus) on Linux.

This fact, combined with Unix shell scripting's natural
habitat -- which is, naturally... *drumroll*... Unix --
often has unintended side effects, where developers expect the test
suite to run in a Unix environment, which is an incorrect assumption.

One instance of this problem can be observed in the 'difftool --dir-diff
handles modified symlinks' test case in `t7800-difftool.sh`, which
assumes that all absolute paths start with a forward slash. That
assumption is incorrect in general, e.g. on Windows, where absolute
paths have many shapes and forms, none of which starts with a forward
slash.

The only saving grace is that this test case is currently not run on
Windows because of the `SYMLINK` prerequisite. However, I am currently
working towards upstreaming symbolic link support from Git for Windows
to upstream Git, which will put a crack into that saving grace.

Let's change that test case so that it does not rely on absolute paths
(which are passed to the "external command" `ls` as parameters and are
therefore part of its output, and which the test case wants to filter
out before verifying that the output is as expected) starting with a
forward slash. Let's instead rely on the much more reliable fact that
`ls` will output the path in a line that ends in a colon, and simply
filter out those lines by matching said colon instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t7800-difftool.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 9b74db5563..bf0f67378d 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -752,11 +752,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 		c
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	# The left side contains symlink "c" that points to "b"
@@ -786,11 +786,11 @@ test_expect_success SYMLINKS 'difftool --dir-diff handles modified symlinks' '
 
 	EOF
 	git difftool --symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual &&
 
 	git difftool --no-symlinks --dir-diff --extcmd ls >output &&
-	grep -v ^/ output >actual &&
+	grep -v ":\$" output >actual &&
 	test_cmp expect actual
 '
 
-- 
gitgitgadget

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

[Junio C Hamano]

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

> Changes since v3:
>
>  * Re-added the credits to Patrick's research that was accidentally dropped
>    from the commit message of "t0600: fix incomplete prerequisite for a test
>    case"

This matched what I expected to see.  Will replace with this
iteration to keep the Message-Ids of the commits straight.

Thanks.