Hi Jeff,

On Tue, 18 Nov 2025, Jeff King wrote:

The GitHub windows-meson-test jobs directly run "meson test" with the
--slice option. This means they skip all of the ci/lib.sh
infrastructure, and in particular:

  1. They do not actually set any GIT_TEST_OPTS like --verbose-log or
     -x.

  2. They do not do the usual handle_failed_tests() magic to print test
     failures or tar up failed directories.

As a result, you get almost no feedback at all when a test fails in this
job, making debugging rather tricky.

Let's try to make this behave more like the other CI jobs. Because we're
on Windows, we can't just use the normal run-build-and-tests.sh script.
Our build runs as a separate job (like the non-meson Windows job), and
then we parallelize the tests across several job slices. So we need
something like the run-test-slice.sh script that the "windows-test" job
uses.

In theory we could just swap out the "make" invocation there for
"meson". But it doesn't quite work, because "make" knows how to pull
GIT_TEST_OPTS out of GIT-BUILD-OPTIONS automatically. But for meson, we
have to extract them into the --test-args option ourselves. I tried
making the logic in run-test-slice.sh conditional, but there ended up
being hardly any common code at all (and there are some tricky ordering
constraints). So I added up with a new meson-specific test-slice runner.

Signed-off-by: Jeff King <redacted>
---

Thank you for fixing this. The patch looks good to me.

I cannot help but wonder whether switching to Meson was worth it, as we're
not only deviating from the mainstream (if MSYS2 is any indication, Meson
usage is negligible: 16 packages use it in MSYS2, 294 use CMake, and 975
use GNU make), but also are forced to repeat the very same steps we
already took for `make`-based builds and then for CMake builds. This very
much makes me think of some saying I vaguely remember that involves
history and something about repetitions.

BTW, one curiosity. I tried swapping out "pwsh" as the shell for "bash",
to match what the non-meson test does. And it _mostly_ works, but
curiously it causes a handful of mergetool tests to fail (it looks like
maybe "c:\foo" Windows-style paths get used where we expect "/c/foo"
paths). I didn't dig further, and just added it to my "things that
confuse and terrify me about Windows" list.

Indeed, the path conversion kicks in, where `/mingw64` gets converted to
`D:\git-for-windows-minimal\mingw64` or something like that so that
PowerShell isn't losing its mind over paths that simply don't exist. When
you then call Bash (implicitly, as you know all too well Git's test suite
depends on it in a major way, which is still a shame), this conversion is
not reverted, at least not fully.

Ciao,
Johannes