Description
In git-for-windows/msys2-runtime#48, we tried to make sure that Git for Windows' MSYS2 runtime does not even try to access the information in the cygheap of another MSYS2 runtime version.
However, the indicator used by this PR is the Cygwin version. That's not good enough because there are sometimes changes in Git for Windows' MSYS2 runtime that leave the Cygwin version alone.
For example, the recent backport of the fix for less hanging after a window resize left the MSYS2 runtime version at 3.3.6-341 but trying to use the cygheap across the previous and the current version of the MSYS2 runtime in Git for Windows simply leads to a terse exit code 127 without any other error message.
This workflow run demonstrates two instances of the symptoms: when calling gzip.exe from tar.exe where gzip.exe uses the current MSYS2 runtime while tar.exe uses the previous version, and when calling base64.exe that uses the previous MSYS2 runtime from a bash.exe that uses the current version.
While we have a PR to work around this issue in the open-pr workflow, a fuller fix is required e.g. to address actions/cache#1092 and actions/cache#1073.
Since Git v2.40.0-rc0 is just around the corner, we need to address this issue rather quickly.
My current idea is to add the information about the current commit via a new option of the MSYS2 runtime's ./configure and use that instead of the Cygwin runtime version when trying to avoid reusing cygheaps across processes.
As a bonus, this will allow us to adjust the output of uname -r to make it more useful.
A slight complication is that the actual build of the msys2-runtime package does not use the git-for-windows/msys2-runtime repository at all, but replays the commits directly on top of the tagged Cygwin revision. This means that we will have to patch not only configure.ac and friends in addition to adjusting the configure call in PKGBUILD, but we also have to adjust update-patches.sh to record the commit hash.