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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 30, 2025, 06:49 UTC
Message-ID: <xmqqa504c8wa.fsf@gitster.g>
In-Reply-To: <f7f1e91cef81068f3572b745aebc33d1d2a26c06.1764440906.git.gitgitgadget@gmail.com>

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

Show 10 quoted lines

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