Reinstate `mingw-w64-git`, synchronizing the package definition from Git for Windows by dscho · Pull Request #26470 · msys2/MINGW-packages

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.

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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.

ognevny · 2025-11-21T20:11:19Z

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.

in next years older Windows support seems less relevant... I guess there could be issues with maintaining separate target for older systems

edit: and it's only about MINGW{32,64}

dscho · 2026-02-02T19:48:16Z

As soon as the GitHub Actions incident is resolved, I can force-push the PR branch and mark this as ready for review, at long last.

ognevny · 2026-02-03T06:11:50Z

As soon as the GitHub Actions incident is resolved, I can force-push the PR branch and mark this as ready for review, at long last.

it now works :)

dscho · 2026-02-03T06:14:03Z

As soon as the GitHub Actions incident is resolved, I can force-push the PR branch and mark this as ready for review, at long last.

it now works :)

Yes, the incident was resolved 5h ago, as of time of writing. I force-pushed, and as soon as I see that the PR build passed without a hitch, I will mark this as Ready for review.

ognevny · 2026-02-03T06:20:25Z

it seems you need to re-run updpkgsums

dscho · 2026-02-03T07:41:33Z

it seems you need to re-run updpkgsums

Of course ;-) I keep forgetting that.

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 <johannes.schindelin@gmx.de>

dscho · 2026-02-03T08:39:08Z

Finally! This is it, at long last: ready for review.

ognevny · 2026-02-03T08:40:19Z

for me it's fine. some nits like metadata can be added in later PRs. waiting for others...

dscho · 2026-02-03T09:35:29Z

some nits like metadata can be added in later PRs.

Cool, cool. I'll synchronize those changes back to Git for Windows so that the mingw-w64-git/ directories of MSYS2 and Git for Windows can be identical. That will allow me to add automation to easily keep MSYS2 up to date as part of Git for Windows' release process.

lazka · 2026-02-04T08:41:27Z

I'd prefer if the .install file would be dropped, at least for now.

It's depending on MINGW_PREFIX which is not the prefix of the package, but the environment you call pacman from, so installing is broken from the MSYS env, and broken when installing from a different env. The files it creates are not namespaced, so uninstalling might break another env. The first one can be fixed by having an .install file per env, like we do in all packages, the later I don't know, depends on what it's trying to achieve.

I get this when installing in MSYS:

mkdir: cannot create directory ‘’: No such file or directory
error: command failed to execute correctly

I get this when installing in the matching env:

cp: cannot stat '/clang64/share/git/compat-bash.exe': No such file or directory

Unrelated to that, uninstalling gave me:

rm: cannot remove '/proc/cygdrive/C/msys64/bin/git.exe': No such file or directory
rm: cannot remove '/proc/cygdrive/C/msys64/bin/bash.exe': No such file or directory
rm: cannot remove '/proc/cygdrive/C/msys64/bin/sh.exe': No such file or directory

dscho · 2026-02-04T12:27:20Z

I'd prefer if the .install file would be dropped, at least for now.

Oh wow, this should only have been part of the git-for-windows-addons package... Sorry for not spotting that earlier.

I's depending on MINGW_PREFIX which is not the prefix of the package, but the environment you call pacman from, so installing is broken from the MSYS env, and broken when installing from a different env. The files it creates are not namespaced, so uninstalling might break another envs. The first one can be fixed by having an .install file per env, like we do in all packages, the later I don't know, depends on what it's trying to achieve.

I get this when installing in MSYS:
mkdir: cannot create directory ‘’: No such file or directory
error: command failed to execute correctly
I get this when installing in the matching env:
cp: cannot stat '/clang64/share/git/compat-bash.exe': No such file or directory
Unrelated to that, uninstalling gave me:
rm: cannot remove '/proc/cygdrive/C/msys64/bin/git.exe': No such file or directory
rm: cannot remove '/proc/cygdrive/C/msys64/bin/bash.exe': No such file or directory
rm: cannot remove '/proc/cygdrive/C/msys64/bin/sh.exe': No such file or directory

True; It should probably hard-code the MINGW_PREFIX at build time. Will experiment with that.

ognevny · 2026-02-05T06:09:29Z

mingw-w64-git/PKGBUILD

+	"${MINGW_PACKAGE_PREFIX}-openssl"
+	"${MINGW_PACKAGE_PREFIX}-pcre2"
+	"${MINGW_PACKAGE_PREFIX}-asciidoctor")
+install=git.install


using git-${MSYSTEM}.install files with hard-coded prefixes can probably help

Right. I actually went for MINGW_PACKAGE_PREFIX instead, and generate it on the fly, but the idea is the same.

Hmm. That did work locally, but not in CI...

better write these install files manually

This file's goal is to ensure that the compatibility wrapper is installed into the `<top>\bin\` directory so that e.g. D:\path\to\msys2\bin\sh.exe -lc "echo Hello" would work. These wrappers are totally inappropriate for the mingw-w64-git package and should therefore not be installed via the `.install` script. Instead, let's move it to the place that is totally appropriate a place for this: the mingw-w64-git-for-windows-addons package which already installs wrappers like `<top>\git-bash.exe`. This commit is best viewed with `--color-moved`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of the Git wrapper is that it is installed into various places (as part of the `mingw-w64-git-for-windows-addons` package), e.g. into `<msys64>\git-bash.exe`. This executable will then set up the required environment variables and spawn the actual `bash.exe`. Likewise, the Git wrapper is installed into `<msys64>\cmd\git.exe` where it can be called directly from, say, a PowerShell, without needing to add all the correct `PATH` entries and without setting `MSYSTEM`: the wrapper will do all that, and then spawn the actual `git.exe` in the correct subdirectory. Now, grace to Git for Windows' history, which started out before MSYS2 was invented and was based on MSys and MinGW instead, the actual logic grew organically. In the early days, when Git for Windows only supported i686 builds, all of those environment variable values were hardcoded. Later, when Git for Windows was moved on top of MSYS2, only two values were possible: "MINGW64" and "MINGW32". When timid steps were taken to support Windows/ARM64, a third option was added: "CLANGARM64". All this was unnecessary, though: The environment variable `MSYSTEM` is set when building the mingw-w64-git package, and it is guaranteed to be set to the very value the Git wrapper wants to use at run-time. So let's stop hard-coding the MINGW{32,64} values, and drop the hack we needed in Git for Windows while the clangarm64 builds were only experimental. Instead, just use the value in the environment variable `MSYSTEM` at build time, hard-coding _that_ into the binary. This will allow the Git wrapper to find the executables that were put into the corresponding `mingw-w64-git-*` packages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2026-02-05T11:55:55Z

Good that y'all pointed me to the .install file! Its purpose is (limited to the git-for-windows-addons package!) to add a few compatibility executables: <msys2>\bin\git.exe and <msys2>\bin\sh.exe. The <msys2>\bin folder does not exist in MSYS2, but it did exist in MSys/MinGW (the ecosystem on which Git for Windows was originally based).

If you hadn't pointed me to this, I wouldn't have verified that they work for, say, the UCRT64 version. I did test that, realized that some major changes were still needed in git-wrapper.c, and made those changes. They are not big, just... major (instead of hard-coding the MSYSTEM and dependent values based on the compiler's pre-defined CPU architecture constants, now the MSYSTEM value at build time is respected). Here they are, tested and verified: e452dfe...8679563

dscho · 2026-02-08T12:32:36Z

@ognevny @lazka anything else you'd like me to change?

lazka · 2026-02-08T12:50:08Z

Still not a fan of the conflicting files between envs, but it's now contained within the addons package, so easily avoided.

  +/cmd/
  +/cmd/git.exe
  +/cmd/git-gui.exe
  +/cmd/gitk.exe
  +/cmd/git-receive-pack.exe
  +/cmd/git-upload-pack.exe
  +/cmd/scalar.exe
  +/cmd/start-ssh-agent.cmd
  +/cmd/start-ssh-pageant.cmd
  +/cmd/tig.exe
  +/git-bash.exe
  +/git-cmd.exe

dscho · 2026-02-08T14:01:29Z

Still not a fan of the conflicting files between envs, but it's now contained within the addons package, so easily avoided.
  +/cmd/
  +/cmd/git.exe
  +/cmd/git-gui.exe
  +/cmd/gitk.exe
  +/cmd/git-receive-pack.exe
  +/cmd/git-upload-pack.exe
  +/cmd/scalar.exe
  +/cmd/start-ssh-agent.cmd
  +/cmd/start-ssh-pageant.cmd
  +/cmd/tig.exe
  +/git-bash.exe
  +/git-cmd.exe

Right, those are unfortunately intentional, as "global shortcuts" for the intended git.exe. The alternative would be to copy those files as part of the post_install hook, but that would silently conflict between the architectures, with a "last installed wins" behavior, which I find even worse. The intended rule is that really only one git-for-windows-addons package can be installed.

Also, I do not expect this package to be installed all that often. The only reason why it exists here is that I really want to have identical contents of mingw-w64-git/ in this here repository and in Git for Windows' fork. That will make synchronizing a no-brainer.

500-internal-server-error · 2026-02-08T15:15:11Z

The intended rule is that really only one git-for-windows-addons package can be installed.

Perhaps make it provides and conflicts with itself then? That way only one env can be installed at a time.

MagielBruntink · 2026-02-08T15:31:04Z

This is fantastic; big step forward for git on windows. Thank you all for the effort!

lazka · 2026-02-08T16:01:20Z

One random observation, native git is quite a bit slower for me compared to the cygwin version:

# cygwin
$ time /usr/bin/git --version
real    0m0.013s
$ time /usr/bin/git rev-parse --git-dir --is-inside-git-dir --is-bare-repository --is-inside-work-tree --show-ref-format --short HEAD
real    0m0.018s

# native
$ time git --version
real    0m0.096s
$ time git rev-parse --git-dir --is-inside-git-dir --is-bare-repository --is-inside-work-tree --show-ref-format --short HEAD
real    0m0.110s

at least for these simple operations, which makes my PS1 laggy. For large repos it's faster (gcc repo here):

# native
$ time git status
real    0m0.602s
# cygwin
$ time /usr/bin/git status
real    0m1.048s

lazka · 2026-02-08T16:09:26Z

Ah, I think that's just general cygwin slowness/overhead when calling native things. meh.

MagielBruntink · 2026-02-08T16:35:48Z

Ah, I think that's just general cygwin slowness/overhead when calling native things. meh.

Are you sure that git config is identical? Cygwin and native versions can store them in different places.

mati865 · 2026-02-08T16:50:44Z

Interestingly Git for Windows shell is much faster:

$ which jj
/g/msys64/clang64/bin/jj

$ time jj --version
jj 0.37.0-11c3dbe17ac0a2172755789613fa8f04a50118a0
real    0m0,032s

$ time git --version
git version 2.51.0.windows.2
real    0m0,027s

MSYS2:

$ which jj
/clang64/bin/jj

$ time jj --version
jj 0.37.0-11c3dbe17ac0a2172755789613fa8f04a50118a0
real    0m0.095s

$ time git --version
git version 2.53.0.windows.1
real    0m0.095s

$ time /usr/bin/git --version
git version 2.53.0
real    0m0.015s