Reinstate `mingw-w64-git`, synchronizing the package definition from Git for Windows #26470

dscho · 2025-11-20T08:45:14Z

Ever since I moved Git for Windows from MSys to MSYS2 in 2015, I have dreamed of this: To share the identical package definition of mingw-w64-git with MSYS2. This will allow MSYS2 users to benefit from Git for Windows within their regular MSYS2 setup, while allowing existing Git for Windows users to continue using the official installer to install and upgrade.

This here PR is a vital part of the initiative laid out in #16383.

mingw-w64-git/PKGBUILD

dscho · 2025-11-20T10:30:24Z

@ognevny I notice that the CLANGARM64 job does not build any packages. Is there any trick to this?

mingw-w64-git/PKGBUILD

ognevny · 2025-11-20T10:35:49Z

@ognevny I notice that the CLANGARM64 job does not build any packages. Is there any trick to this?

I've put a suggestion in proper place. there was a missing field

ognevny · 2025-11-20T10:39:20Z

by the way there was a compiler error about using 32-bit time. why is this important for GfW?
git history seems not clean after rebase...

dscho · 2025-11-20T10:39:34Z

wasi-libc: update to 0+503+ac020b86

zed: update to 0.213.3

openexr: update to 3.4.4

Whoops. Will of course drop them when cleaning up this PR branch.

I am about to introduce the first such file, and it should not have its "line endings" converted from CR/LF to LF. Signed-off-by: Johannes Schindelin <[email protected]>

dscho · 2025-11-20T10:52:33Z

by the way there was a compiler error about using 32-bit time. why is this important for GfW?

You mean this:

D:/M/msys64/ucrt64/include/corecrt.h:128:2: error: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
    128 | #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
        |  ^~~~~

Wow, that required some digging. That _USE_32BIT_TIME_T stems from git-for-windows/git@fa93bb2, i.e. way before we switched from MinGW to mingw-64. Let's see whether it is possible to drop this flag.

rimrul · 2025-11-20T11:23:34Z

Wow, that required some digging. That _USE_32BIT_TIME_T stems from git-for-windows/git@fa93bb2, i.e. way before we switched from MinGW to mingw-64.

Isn't this only part of the issue that config.mak.uname treats all native envs beside MINGW64 and CLANGARM64 as MINGW32?

dscho · 2025-11-20T11:44:42Z

Wow, that required some digging. That _USE_32BIT_TIME_T stems from git-for-windows/git@fa93bb2, i.e. way before we switched from MinGW to mingw-64.

Isn't this only part of the issue that config.mak.uname treats all native envs beside MINGW64 and CLANGARM64 as MINGW32?

It totally is. That's the reason for the -large-address-aware problem in UCRT64.

For now, I'd like to get the build green so as to know what has to be done, and then fix git-for-windows/git properly. Unfortunately, those fixes won't be in a tagged version immediately, but with a little bit of "luck", there will be a v2.52.1 anyway, and if I can get the fixes into the code base before that, we're good to go.

mingw-w64-git/PKGBUILD

This option was added in fa93bb2 (MinGW: Fix stat definitions to work with MinGW runtime version 4.0, 2013-09-11), i.e. a _long_ time ago. So long, in fact, that it still targeted MinGW. But we switched to mingw-w64 in 2015, which seems not to share the problem, and therefore does not require a fix. Even worse: This flag is incompatible with UCRT64, which we are about to support by way of upstreaming `mingw-w64-git` to the MSYS2 project, see msys2/MINGW-packages#26470 for details. So let's send that option into its well-deserved retirement. Signed-off-by: Johannes Schindelin <[email protected]>

There are now a good deal of work-arounds for things in git-for-windows/git that need to be adjusted before we can mark msys2#26470 as ready for review. Better develop the patches directly in the Git repository than playing more of those `config.mak` and `sed` games. This here commit will of course be dropped as soon as things work and the git-for-windows/git patches made it into a tagged version of Git for Windows. Signed-off-by: Johannes Schindelin <[email protected]>

ognevny · 2025-11-21T18:02:11Z

by the way, can we try to enable rust like in msys2/MSYS2-packages#5812? (but with mingw-w64-rust)

rimrul · 2025-11-21T19:45:07Z

by the way, can we try to enable rust like in msys2/MSYS2-packages#5812? (but with mingw-w64-rust)

Could we keep that as a separate second step?
@dscho has mentioned wanting to keep the package definitions somewhat in sync between Msys2 and Git for Windows and we'll need some preparing for a mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

ognevny · 2025-11-21T19:47:45Z

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it? I mean win7 target

dscho · 2025-11-21T20:07:14Z

by the way, can we try to enable rust like in msys2/MSYS2-packages#5812? (but with mingw-w64-rust)

Good idea! Rust won't stay optional forever, Git's planning on making it mandatory by the end of next year.

Maybe we should leave that for a follow-up PR, though. It'll take some work to get the fixes into Git for Windows, and I get the sense, after reading on the Git mailing list about the last-modified issues and about the :(optional) segfault, that Git v2.52.0 might not be the most robust, and there might be a v2.52.1 soon, which would be the perfect opportunity to integrate the fixes which I developed in this PR's context into git-for-windows/git and then into a tagged version.

In other words, Rust isn't my highest priority right now :-)

ognevny · 2025-11-21T20:08:48Z

no hurries with Rust, just a suggestion

dscho · 2025-11-21T20:09:06Z

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it?

Rust will be mandatory in Git soon and yes, we will need to keep supporting Windows 8.1 and I have been led to believe that this Rust toolchain version is the only one that could provide that support.

rimrul · 2025-11-21T20:10:39Z

mingw-w64-rust setup with *-win7-windows-gnu targets on the Git for Windows side.

do you actually need it? I mean win7 target

Yes. We do intend to keep supporting Windows 8.1 for now, so it's either win7 targets on MINGW32 and MINGW64 (at least in Git for Windows, not necessarily in Msys2) or older rust.

Kreijstal · 2025-11-24T18:33:56Z

this is beautiful

As part of my effort to upstream the `mingw-w64-git` package definition to MSYS2, I had to change the default to _omit_ building `mingw-w64-git-pdb`. Before marking [the upstreaming PR](msys2/MINGW-packages#26470) as ready for review, I want to ensure that Git for Windows already has the identical changes (see git-for-windows/MINGW-packages#174). This requires two changes in `build-extra` to accommodate for the now-inverted logic.

In #172, I already prepared a bit for "upstreaming" the `mingw-w64-git` package (the plan is not to throw it over the wall, but to maintain it synchronously between MSYS2 and Git for Windows). When I started the _actual_ upstreaming process in msys2#26470, though, I discovered another few loose ends that need to be covered.

Every once in a while, there are bug reports in Git for Windows' bug tracker that describe an issue running [inside MSYS2 proper](https://gitforwindows.org/install-inside-msys2-proper), totally ignoring the big, honking warning on top of [the page](https://gitforwindows.org/install-inside-msys2-proper) that spells out clearly that this is an unsupported use case. At the same time, we cannot easily deflect and say "just use MSYS2 directly" (and leave the "and stop pestering us" out). We cannot do that because there is only an _MSYS_ `git` package in MSYS2 (i.e. a Git that uses the quite slow POSIX emulation layer provided by the MSYS2 runtime), but no `mingw-w64-git` package (which would be equivalent in speed to Git for Windows). In msys2/MINGW-packages#26470, I am preparing to change that. As part of that PR, I noticed and fixed a couple of issues _in `git-for-windows/git` that prevented full support for `mingw-w64-git` in MSYS2, such as problems with CLANG64 and UCRT64. While at it, I simplified the entire setup to trust MSYS2's `MINGW_PREFIX` & related environment variables instead of hard-coding values like the installation prefix and what `MSYSTEM` to fall back on if it is unset.

This option was added in fa93bb2 (MinGW: Fix stat definitions to work with MinGW runtime version 4.0, 2013-09-11), i.e. a _long_ time ago. So long, in fact, that it still targeted MinGW. But we switched to mingw-w64 in 2015, which seems not to share the problem, and therefore does not require a fix. Even worse: This flag is incompatible with UCRT64, which we are about to support by way of upstreaming `mingw-w64-git` to the MSYS2 project, see msys2/MINGW-packages#26470 for details. So let's send that option into its well-deserved retirement. Signed-off-by: Johannes Schindelin <[email protected]>

Every once in a while, there are bug reports in Git for Windows' bug tracker that describe an issue running [inside MSYS2 proper](https://gitforwindows.org/install-inside-msys2-proper), totally ignoring the big, honking warning on top of [the page](https://gitforwindows.org/install-inside-msys2-proper) that spells out clearly that this is an unsupported use case. At the same time, we cannot easily deflect and say "just use MSYS2 directly" (and leave the "and stop pestering us" out). We cannot do that because there is only an _MSYS_ `git` package in MSYS2 (i.e. a Git that uses the quite slow POSIX emulation layer provided by the MSYS2 runtime), but no `mingw-w64-git` package (which would be equivalent in speed to Git for Windows). In msys2/MINGW-packages#26470, I am preparing to change that. As part of that PR, I noticed and fixed a couple of issues _in `git-for-windows/git` that prevented full support for `mingw-w64-git` in MSYS2, such as problems with CLANG64 and UCRT64. While at it, I simplified the entire setup to trust MSYS2's `MINGW_PREFIX` & related environment variables instead of hard-coding values like the installation prefix and what `MSYSTEM` to fall back on if it is unset.

I'd like to foster tighter collaboration between the Git for Windows and the MSYS2 project, as I documented here: msys2#16383 As part of that effort, here is the exact same package definition of the `mingw-w64-git` package as Git for Windows uses, as per https://github.com/git-for-window/MINGW-packages/commit/fa6b8ebc02 (Prepare some more for upstreaming `mingw-w64-git` to MSYS2 (git-for-windows#174), 2025-11-25). Note: As part of this effort, I have split out the Git for Windows-specific part from that package that would be highly inappropriate in MSYS2's context: For example, Git for Windows comes with a `git-bash.exe` in the top-level directory, and it also installs its logo into `$MINGW_PREFIX/share/git/`. These now live in the `mingw-w64-git-for-windows-addons` package. This is not the first time that a `mingw-w64-git` package definition has lived in this here repository: Six years ago, such a definition was removed (as "deprecated"), in 446b69f (More cleanup for packages. Move all packages not provided by pacman and deprecated to new repo https://github.com/msys2/MINGW-packages-dev, 2019-06-03). The chances of success are much better now, though: Git for Windows is much more mature now, and already collaborates highly successfully with the MSYS2 project in the msys2-runtime repository. So there is precedent for fruitful and friendly working together. Besides, all of the blockers are resolved that would have let Git's test suite fail due to differences in the MSYS2 runtime or in other parts of the tree. Signed-off-by: Johannes Schindelin <[email protected]>

… hack In git/git@436a42215e5 (max_tree_depth: lower it for clangarm64 on Windows, 2025-04-23), I worked around a vexing, ARM64-specific bug in the tree-depth restriction where Git ran into a ``STATUS_STACK_OVERFLOW` that Git simply could not handle correctly. This bug might not actually be limited to the specific circumstances for which I instated that work-around. Let's verify as part of the build that this work-around is complete enough as far as MSYS2 is concerned. Technically, this should live in the `check` function, not in the `build` function. But in MSYS2's PullRequests, the `check` part is deliberately omitted, so we cannot use that approach. Signed-off-by: Johannes Schindelin <[email protected]>

…nges I made a couple of changes to stop hard-coding the fall-back values of `MSYSTEM` and `MINGW_PREFIX` in Git's C code and instead rely on the environment variables' values that are in effect while building. This was needed to extend the support from the three `MSYSTEM` values originally supported by Git for Windows to all six supported by MSYS2. Let's verify that those changes work as expected. Signed-off-by: Johannes Schindelin <[email protected]>

There are now a good deal of work-arounds for things in git-for-windows/git that need to be adjusted before we can mark msys2#26470 as ready for review. Better develop the patches directly in the Git repository than playing more of those `config.mak` and `sed` games. This here commit will of course be dropped as soon as things work and the git-for-windows/git patches made it into a tagged version of Git for Windows. Signed-off-by: Johannes Schindelin <[email protected]>

ognevny · 2025-11-28T17:02:34Z

you can also calculate checksum for git repo if commit is set

dscho · 2025-11-28T18:55:48Z

you can also calculate checksum for git repo if commit is set

I know, but I'd like to update only when a new version is tagged.

dscho · 2025-11-28T18:59:33Z

main / UCRT64 (pull_request)Failing after 20m

Seems to be a transient network error:

   Total Download Size:    28.60 MiB
  Total Installed Size:  408.90 MiB
  
  :: Proceed with installation? [Y/n] 
  :: Retrieving packages...
  error: failed retrieving file 'mingw-w64-ucrt-x86_64-python-3.12.12-1-any.pkg.tar.zst.sig' from ftp2.osuosl.org : Connection timed out after 10001 milliseconds

The same job succeeds in my fork, on the same commit.

ognevny · 2025-11-28T19:00:43Z

yeah, sometimes happens. restarted the job

lazka · 2025-11-28T19:14:19Z

Seems to be a transient network error:

could be https://gitlab.archlinux.org/pacman/pacman/-/issues/274