"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > ... > This bug in the MSYS2 runtime has been fixed in the meantime, which is > the reason why the same test case causes no problems in the `win test` > and the `vs test` jobs. > > This will continue to be the case until the Git for Windows version on > the GitHub runners is upgraded to a version that distributes a newer > MSYS2 runtime version. However, as of time of writing, this _is_ the > latest Git for Windows version, and will be for another 1.5 weeks, until > Git v2.50.0 is scheduled to appear (and shortly thereafter Git for > Windows v2.50.0). Traditionally it takes a while before the runners pick > up the new version. > ... > I finally had a chance to look more closely at this problem. Here is my > alternative to what Patrick proposed in > https://lore.kernel.org/git/aD7tKfXD7YxprSZh@xxxxxx/. Superb. It must have taken a truly heroic effort. Thanks and congratulations for finally solving the puzzle. I do agree that Patrick's "wrap the same in a script" smelled like shifting a timing issue and not truly a solution. > +# The `tee.exe` shipped in Git for Windows v2.49.0 is known to hang frequently > +# when spawned from `git.exe` and piping its output to `git.exe`. This seems > +# related to MSYS2 runtime bug fixes regarding the signal handling; Let's just > +# skip the tests that need to exercise this when the faulty MSYS2 runtime is > +# detected; The test cases are exercised enough in other matrix jobs of the CI > +# runs. > +test_lazy_prereq TEE_DOES_NOT_HANG ' > + test_have_prereq !MINGW && > + case "$(uname -a)" in *3.5.7-463ebcdc.x86_64*) false;; esac > +' That's very specific ;-). As this is not in a library-ish part, it does not have to be lazy. Anybody running this test script need to tell if their environment satisfies the prerequisite, but lazy one does have a documentation value, I guess, and a bit of extra indirection does not hurt. Will queue. Thanks again.
