mingw: handle GITPERLLIB in t0021 in a Windows-compatible way

Git's assumption that all path lists are colon-separated is not only
wrong on Windows, it is not even an assumption that is compatible with
POSIX.

In the interest of time, let's not try to fix this properly but simply
work around the obvious breakage on Windows, where the MSYS2 Bash used
by Git for Windows to interpret the Git's Unix shell scripts will
automagically convert path lists in the environment to
semicolon-separated lists of Windows paths (with drive letter and the
corresponding colon and all that jazz).

In other words, we simply look whether there is a semicolon in
GITPERLLIB and split by semicolons if found instead of colons. This is
not fool-proof, of course, as the path list could consist of a single
path. But that is not the case in Git for Windows' test suite, there are
always two paths in GITPERLLIB.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 16 insertions, 1 deletions

diff --git a/t/t0021/rot13-filter.pl b/t/t0021/rot13-filter.pl
index f1678851de..470107248e 100644
--- a/t/t0021/rot13-filter.pl
+++ b/t/t0021/rot13-filter.pl
@@ -31,7 +31,22 @@
 #
 
 use 5.008;
-use lib (split(/:/, $ENV{GITPERLLIB}));
+sub gitperllib {
+	# Git assumes that all path lists are Unix-y colon-separated ones. But
+	# when the Git for Windows executes the test suite, its MSYS2 Bash
+	# calls git.exe, and colon-separated path lists are converted into
+	# Windows-y semicolon-separated lists of *Windows* paths (which
+	# naturally contain a colon after the drive letter, so splitting by
+	# colons simply does not cut it).
+	#
+	# Detect semicolon-separated path list and handle them appropriately.
+
+	if ($ENV{GITPERLLIB} =~ /;/) {
+		return split(/;/, $ENV{GITPERLLIB});
+	}
+	return split(/:/, $ENV{GITPERLLIB});
+}
+use lib (gitperllib());
 use strict;
 use warnings;
 use IO::File;