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:

quoted

 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