Migrate the SDK from MINGW64 to UCRT64 by dscho · Pull Request #117 · git-for-windows/git-sdk-64

dscho · 2026-06-06T18:56:34Z

MSYS2 deprecated MINGW64 a while back; new packages no longer get accepted there, and updates of the ones we already ship have been winding down. The SDK has to move over to UCRT64 before what we ship there starts to bit-rot.

This branch only adds the piece that kicks the move off: a workflow that runs inside this PR, pulls in the UCRT64 equivalent of every MINGW64 package we currently have installed, and then takes the old MINGW64 and MINGW32 packages back out. The PR is a draft so the resulting commits can be looked at before any of it lands on main.

The plan was sketched in git-for-windows/git#6018 (reply in thread).

MSYS2 has deprecated MINGW64. Upstream no longer accepts new packages targeting that environment and is winding down updates for the ones we already ship, so anything we do not migrate is going to rot in place. UCRT64 is the supported successor for the x86_64 target, and Git for Windows therefore has to follow. Rather than spin up a separate `git-sdk-ucrt-64` repository just for the new environment, we want to keep everything in this repo and make the cutover happen on a `ucrt64` branch that eventually becomes `main`. To produce the converted tree without running `pacman` manually, many times, and committing the resulting churn, this commit adds a one-shot workflow that performs exactly that work inside the PR opened from the `ucrt64` branch: it installs the UCRT64 counterpart of every currently-installed MINGW64 package, then uninstalls every MINGW64 package, then uninstalls every MINGW32 package. Each phase becomes one giant commit like the ones produced by the `sync` workflow. This approach was brain-stormed and documented in git-for-windows/git#6018 (reply in thread). Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Installed UCRT64 packages: mingw-w64-ucrt-x86_64-7zip mingw-w64-ucrt-x86_64-antiword mingw-w64-ucrt-x86_64-asciidoctor mingw-w64-ucrt-x86_64-binutils mingw-w64-ucrt-x86_64-brotli mingw-w64-ucrt-x86_64-bzip2 mingw-w64-ucrt-x86_64-c-ares mingw-w64-ucrt-x86_64-ca-certificates mingw-w64-ucrt-x86_64-connect mingw-w64-ucrt-x86_64-crt mingw-w64-ucrt-x86_64-curl-winssl mingw-w64-ucrt-x86_64-expat mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gcc-libs mingw-w64-ucrt-x86_64-gdb mingw-w64-ucrt-x86_64-gdbm mingw-w64-ucrt-x86_64-gettext-libtextstyle mingw-w64-ucrt-x86_64-gettext-runtime mingw-w64-ucrt-x86_64-gettext-tools mingw-w64-ucrt-x86_64-git mingw-w64-ucrt-x86_64-git-credential-wincred mingw-w64-ucrt-x86_64-git-doc-html mingw-w64-ucrt-x86_64-git-for-windows-addons mingw-w64-ucrt-x86_64-git-gui mingw-w64-ucrt-x86_64-git-lfs mingw-w64-ucrt-x86_64-git-perl mingw-w64-ucrt-x86_64-git-send-email mingw-w64-ucrt-x86_64-git-subtree mingw-w64-ucrt-x86_64-git-svn mingw-w64-ucrt-x86_64-gitk mingw-w64-ucrt-x86_64-gmp mingw-w64-ucrt-x86_64-gnutls mingw-w64-ucrt-x86_64-headers mingw-w64-ucrt-x86_64-isl mingw-w64-ucrt-x86_64-libb2 mingw-w64-ucrt-x86_64-libffi mingw-w64-ucrt-x86_64-libiconv mingw-w64-ucrt-x86_64-libidn2 mingw-w64-ucrt-x86_64-libmangle mingw-w64-ucrt-x86_64-libpsl mingw-w64-ucrt-x86_64-libssh2-wincng mingw-w64-ucrt-x86_64-libsystre mingw-w64-ucrt-x86_64-libtasn1 mingw-w64-ucrt-x86_64-libtre mingw-w64-ucrt-x86_64-libunistring mingw-w64-ucrt-x86_64-libwinpthread mingw-w64-ucrt-x86_64-libyaml mingw-w64-ucrt-x86_64-libzip mingw-w64-ucrt-x86_64-mpc mingw-w64-ucrt-x86_64-mpdecimal mingw-w64-ucrt-x86_64-mpfr mingw-w64-ucrt-x86_64-ncurses mingw-w64-ucrt-x86_64-nettle mingw-w64-ucrt-x86_64-nghttp2 mingw-w64-ucrt-x86_64-odt2txt mingw-w64-ucrt-x86_64-openssl mingw-w64-ucrt-x86_64-osslsigncode mingw-w64-ucrt-x86_64-p11-kit mingw-w64-ucrt-x86_64-pcre mingw-w64-ucrt-x86_64-pcre2 mingw-w64-ucrt-x86_64-pkgconf mingw-w64-ucrt-x86_64-python mingw-w64-ucrt-x86_64-readline mingw-w64-ucrt-x86_64-ruby mingw-w64-ucrt-x86_64-sqlite3 mingw-w64-ucrt-x86_64-tcl mingw-w64-ucrt-x86_64-termcap mingw-w64-ucrt-x86_64-tk mingw-w64-ucrt-x86_64-tools mingw-w64-ucrt-x86_64-tzdata mingw-w64-ucrt-x86_64-windows-default-manifest mingw-w64-ucrt-x86_64-wineditline mingw-w64-ucrt-x86_64-winpthreads mingw-w64-ucrt-x86_64-xxhash mingw-w64-ucrt-x86_64-xz mingw-w64-ucrt-x86_64-zlib mingw-w64-ucrt-x86_64-zstd No UCRT64 counterpart in the configured Pacman repositories (skipped): mingw-w64-x86_64-busybox mingw-w64-x86_64-curl-openssl-alternate mingw-w64-x86_64-cv2pdb mingw-w64-x86_64-git-credential-manager mingw-w64-x86_64-git-extra mingw-w64-x86_64-wintoast mingw-w64-x86_64-xpdf-tools Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

Removed MINGW64 packages: mingw-w64-x86_64-7zip mingw-w64-x86_64-antiword mingw-w64-x86_64-asciidoctor mingw-w64-x86_64-binutils mingw-w64-x86_64-brotli mingw-w64-x86_64-busybox mingw-w64-x86_64-bzip2 mingw-w64-x86_64-c-ares mingw-w64-x86_64-ca-certificates mingw-w64-x86_64-connect mingw-w64-x86_64-crt mingw-w64-x86_64-curl-openssl-alternate mingw-w64-x86_64-curl-winssl mingw-w64-x86_64-cv2pdb mingw-w64-x86_64-expat mingw-w64-x86_64-gcc mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-gdb mingw-w64-x86_64-gdbm mingw-w64-x86_64-gettext-libtextstyle mingw-w64-x86_64-gettext-runtime mingw-w64-x86_64-gettext-tools mingw-w64-x86_64-git mingw-w64-x86_64-git-credential-manager mingw-w64-x86_64-git-credential-wincred mingw-w64-x86_64-git-doc-html mingw-w64-x86_64-git-extra mingw-w64-x86_64-git-gui mingw-w64-x86_64-git-lfs mingw-w64-x86_64-git-perl mingw-w64-x86_64-git-send-email mingw-w64-x86_64-git-subtree mingw-w64-x86_64-git-svn mingw-w64-x86_64-gitk mingw-w64-x86_64-gmp mingw-w64-x86_64-gnutls mingw-w64-x86_64-headers mingw-w64-x86_64-isl mingw-w64-x86_64-libb2 mingw-w64-x86_64-libffi mingw-w64-x86_64-libiconv mingw-w64-x86_64-libidn2 mingw-w64-x86_64-libmangle mingw-w64-x86_64-libpsl mingw-w64-x86_64-libssh2-wincng mingw-w64-x86_64-libsystre mingw-w64-x86_64-libtasn1 mingw-w64-x86_64-libtre mingw-w64-x86_64-libunistring mingw-w64-x86_64-libwinpthread mingw-w64-x86_64-libyaml mingw-w64-x86_64-libzip mingw-w64-x86_64-mpc mingw-w64-x86_64-mpdecimal mingw-w64-x86_64-mpfr mingw-w64-x86_64-ncurses mingw-w64-x86_64-nettle mingw-w64-x86_64-nghttp2 mingw-w64-x86_64-odt2txt mingw-w64-x86_64-openssl mingw-w64-x86_64-osslsigncode mingw-w64-x86_64-p11-kit mingw-w64-x86_64-pcre mingw-w64-x86_64-pcre2 mingw-w64-x86_64-pkgconf mingw-w64-x86_64-python mingw-w64-x86_64-readline mingw-w64-x86_64-ruby mingw-w64-x86_64-sqlite3 mingw-w64-x86_64-tcl mingw-w64-x86_64-termcap mingw-w64-x86_64-tk mingw-w64-x86_64-tools mingw-w64-x86_64-tzdata mingw-w64-x86_64-windows-default-manifest mingw-w64-x86_64-wineditline mingw-w64-x86_64-winpthreads mingw-w64-x86_64-wintoast mingw-w64-x86_64-xpdf-tools mingw-w64-x86_64-xxhash mingw-w64-x86_64-xz mingw-w64-x86_64-zlib mingw-w64-x86_64-zstd Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

Removed MINGW32 packages: mingw-w64-i686-asciidoctor mingw-w64-i686-binutils mingw-w64-i686-brotli mingw-w64-i686-bzip2 mingw-w64-i686-c-ares mingw-w64-i686-ca-certificates mingw-w64-i686-crt mingw-w64-i686-curl-openssl-alternate mingw-w64-i686-curl-winssl mingw-w64-i686-cv2pdb mingw-w64-i686-expat mingw-w64-i686-gcc mingw-w64-i686-gcc-libs mingw-w64-i686-gdb mingw-w64-i686-gdbm mingw-w64-i686-gettext-libtextstyle mingw-w64-i686-gettext-runtime mingw-w64-i686-gettext-tools mingw-w64-i686-gmp mingw-w64-i686-headers mingw-w64-i686-isl mingw-w64-i686-libb2 mingw-w64-i686-libffi mingw-w64-i686-libiconv mingw-w64-i686-libidn2 mingw-w64-i686-libmangle mingw-w64-i686-libpsl mingw-w64-i686-libssh2-wincng mingw-w64-i686-libsystre mingw-w64-i686-libtasn1 mingw-w64-i686-libtre mingw-w64-i686-libunistring mingw-w64-i686-libwinpthread mingw-w64-i686-libyaml mingw-w64-i686-make mingw-w64-i686-mpc mingw-w64-i686-mpdecimal mingw-w64-i686-mpfr mingw-w64-i686-ncurses mingw-w64-i686-nghttp2 mingw-w64-i686-openssl mingw-w64-i686-p11-kit mingw-w64-i686-pcre mingw-w64-i686-pcre2 mingw-w64-i686-pkgconf mingw-w64-i686-python mingw-w64-i686-readline mingw-w64-i686-ruby mingw-w64-i686-sqlite3 mingw-w64-i686-tcl mingw-w64-i686-termcap mingw-w64-i686-tk mingw-w64-i686-tools mingw-w64-i686-tzdata mingw-w64-i686-windows-default-manifest mingw-w64-i686-wineditline mingw-w64-i686-winpthreads mingw-w64-i686-xxhash mingw-w64-i686-xz mingw-w64-i686-zlib mingw-w64-i686-zstd Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

github-actions · 2026-06-06T20:47:13Z

The following MINGW64 packages have no UCRT64 counterpart in the configured Pacman repositories and were skipped:

mingw-w64-x86_64-busybox
mingw-w64-x86_64-curl-openssl-alternate
mingw-w64-x86_64-cv2pdb
mingw-w64-x86_64-git-credential-manager
mingw-w64-x86_64-git-extra
mingw-w64-x86_64-wintoast
mingw-w64-x86_64-xpdf-tools

dscho · 2026-06-06T21:44:37Z

@rimrul here's something to play with ;-)

dscho · 2026-06-07T12:52:14Z

The following MINGW64 packages have no UCRT64 counterpart in the configured Pacman repositories and were skipped:
[...]

Before we can build those, there are a lot of loose ends to address even with this:

adapt the setup-git-for-windows-sdk Action so that it can handle the "architecture" ucrt64 (checking out that branch instead of main, skipping the fast path for minimal/build-installers flavors because there is no pre-built artifact to download)
initialize the UCRT64-only Pacman database (= new file in the x86_64 branch of git-for-windows/pacman-repo)
adjust git-extra so that it adds the UCRT64-only Pacman database in x86_64 Git SDKs (or maybe only in the ucrt-x86_64 variant?)
build tons of packages, not only the ones listed in the previous comment (basically, all the mingw-w64-* ones listed in GitHub - git-for-windows/pacman-repo at x86_64)
hook up ucrt64 into the build-and-deploy and git-installers automation
test, test, test
audit where else in Git for Windows' automation ucrt64 needs to be handled specially
start building snapshots so that helpful contributors can beta-test
everything else I forgot to list here 😉

Now that the SDK is being converted to UCRT64, the minimal-sdk sparse-checkout definition has to follow: every path that previously lived under `/mingw64/` is now under `/ucrt64/`. The MSYS2 GCC triple (`x86_64-w64-mingw32`) and the subdirectory names below it (`lib/gcc/...`, the toolchain `bin/`/`lib/`/`include/` tree) are unchanged, so a plain `/mingw64/` -> `/ucrt64/` rename is enough here. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The bulk of this file is a straight `/mingw64/` -> `/ucrt64/` substitution, just like the minimal-sdk definition that just got adjusted. Two MSYS2 naming differences need separate handling for the asciidoctor/Ruby block, however: the Ruby DLL in the UCRT64 environment is `x64-ucrt-ruby<ver>.dll` rather than the MSVCRT-flavored `x64-msvcrt-ruby<ver>.dll`, and the per-arch subdirectory that Ruby uses for native extensions is `x64-mingw-ucrt/` rather than `x64-mingw32/`. Both of those have to be renamed in tandem with the top-level path, otherwise the sparse checkout would silently skip the Ruby pieces that asciidoctor depends on. `cv2pdb` is still referenced under `/ucrt64/bin/`, even though it currently lacks a UCRT64 counterpart (it's on the skipped-packages list posted by the conversion workflow). That's fine for a sparse-checkout file: it only selects what to materialize once such a package is built and added to the SDK. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This file selects exactly the `/mingw32/` paths needed to build the 32-bit `mingw-w64-git` package out of a partial SDK clone. With the move to UCRT64 we also drop the entire MINGW32 (i686) flavor; there is no UCRT64 i686 environment, and the third conversion commit removes every `mingw-w64-i686-*` package outright. The sparse definition can no longer materialize anything useful, so retire it rather than leave a file that points at directories that will never reappear. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The PR opened from this branch (#117) keeps diverging from `main` (the package-sync commits keep landing there, and the conversion commits keep removing the MINGW64 tree here), so the merge commit GitHub builds for the `pull_request` event is `DIRTY` most of the time. While in that state, GitHub skips the `pull_request` workflow dispatch entirely, which means `ci-artifacts` no longer runs against the PR head and we lose all signal about whether the converted SDK still builds Git. Adding `ucrt64` to the workflow's `push` trigger sidesteps that: pushes to the branch run the workflow directly, without going through a synthetic merge commit, so the build/test matrix stays exercised until the branch is finally merged. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Same reasoning as the matching change to `ci-artifacts.yml`: while the PR opened from this branch (#117) is in a `DIRTY` merge state, GitHub refuses to dispatch `pull_request` events, so the DLL check no longer runs against the PR head. Listing `ucrt64` under the `push` trigger restores coverage directly from the branch tip. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The `test` job of `build-test` is the only PR-time gate that actually runs this Action on a clean Windows runner and pokes at the result; the matrix-based smoke test in `matrix.yml` only fires on manual dispatch. So far that gate has only covered the historical default combination (`flavor: minimal`, `architecture: x86_64`), which means any regression on the new `ucrt64` axis would slip through CI and only surface in a consumer repository. Turn the job into a matrix that adds `architecture: ucrt64` next to the existing `x86_64` row, with `flavor: full` for the UCRT64 entry because that is the only flavor wired up end-to-end at this point (the subset flavors still depend on follow-up work in `build-extra` and on the `ci-artifacts` pipeline of `git-sdk-64`, tracked in git-for-windows/git-sdk-64#117 (comment)). The verification step's previously hard-coded `/mingw64/bin/gcc` becomes `$MINGW_PREFIX/bin/gcc`, with `MINGW_PREFIX` injected from the matrix so it picks up `/mingw64` for the `x86_64` row and `/ucrt64` for the `ucrt64` row. The name follows the MSYS2 ecosystem convention for the per-environment path, which is the same variable the SDK's own shell profile exports. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Now that the preceding commits have actually taught the Action about the `ucrt64` axis, document it in AGENTS.md so the institutional description there matches the code. Add a row to the architecture table covering repository, MSYSTEM, mingw bin path, and current limitations, plus a follow-up paragraph that points at git-for-windows/git-sdk-64#117 and git-for-windows/git-sdk-64#117 (comment) for the larger migration context. Mention in the relationship section that `git-sdk-64` now carries the extra long-lived `ucrt64` branch and that no UCRT64 asset exists in the `ci-artifacts` release, which is why the fast path is forcibly suppressed for that axis. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The manually-triggered `test all artifact flavors` workflow is the closest thing this repository has to an end-to-end smoke test that actually downloads an SDK and runs in-place. Without an entry for the new `ucrt64` axis it would silently keep verifying only the MINGW64 and MINGW32 paths, leaving regressions on the UCRT64 path to surface only in consumer repositories. Add a single `flavor: full, architecture: ucrt64` row via `include`, because that is the only combination wired up end-to-end at this point: the subset flavors still depend on `please.sh create-sdk-artifact` in `build-extra` learning `--architecture=ucrt64` and on a UCRT64 asset appearing in the `ci-artifacts` release of `git-sdk-64`, both tracked in git-for-windows/git-sdk-64#117 (comment). The build-installer step keys off `matrix.flavor == 'build-installers'` and is therefore skipped for the new row, which is exactly what we want. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The `test` job of `build-test` is the only PR-time gate that actually runs this Action on a clean Windows runner and pokes at the result; the matrix-based smoke test in `matrix.yml` only fires on manual dispatch. So far that gate has only covered the historical default combination (`flavor: minimal`, `architecture: x86_64`), which means any regression on the new `ucrt64` axis would slip through CI and only surface in a consumer repository. Turn the job into a matrix that adds `architecture: ucrt64` next to the existing `x86_64` row, with `flavor: full` for the UCRT64 entry because that is the only flavor wired up end-to-end at this point (the subset flavors still depend on follow-up work in `build-extra` and on the `ci-artifacts` pipeline of `git-sdk-64`, tracked in git-for-windows/git-sdk-64#117 (comment)). The verification step's previously hard-coded `/mingw64/bin/gcc` becomes `$MINGW_PREFIX/bin/gcc`, with `MINGW_PREFIX` injected from the matrix so it picks up `/mingw64` for the `x86_64` row and `/ucrt64` for the `ucrt64` row. The name follows the MSYS2 ecosystem convention for the per-environment path, which is the same variable the SDK's own shell profile exports. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This script translates a caller-supplied ARCH into both a directory prefix (MSYSTEM_LOWER) and a Pacman architecture-segment used to filter package names. The existing cases map x86_64 -> mingw64 / x86_64, i.e. they assume the only x86_64 Git for Windows SDK is the MINGW64 one. git-sdk-64 is moving to UCRT64 (git-for-windows/git-sdk-64#117). The new SDK is still x86_64 but its toolchain lives in /ucrt64/ and its Pacman packages are named mingw-w64-ucrt-x86_64-*. Add a dedicated ucrt64 case so callers that explicitly know which flavor they want can pass ARCH=ucrt64 and get the right prefix and package names, without having to teach this script to auto-detect. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

create_sdk_artifact's `case "$architecture" in` ladder hard-maps x86_64 to MSYSTEM=MINGW64 / PREFIX=/mingw64, writes that into the artifact's /etc/profile, and calls make-file-list.sh with ARCH=$architecture. Against the new UCRT64 git-sdk-64 (git-for-windows/git-sdk-64#117), the resulting artifact is broken: the profile points at /mingw64/bin which doesn't exist, and the listed packages all carry the wrong Pacman prefix. Add a new ucrt64 architecture value that maps to MSYSTEM=UCRT64 and PREFIX=/ucrt64 while keeping SDK_REPO=git-sdk-64 (the SDK has not been renamed). The caller asks for the new flavor explicitly; the make-file-list.sh side already knows what ARCH=ucrt64 means after the previous commit. Auto-detection is deliberately left alone: a dual-tree SDK (one with both /mingw64 and /ucrt64) is rare enough that guessing the wrong default would be more surprising than requiring the caller to say what they want. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This script audits import/export DLL references in an SDK installation. It picks the directory prefix from MSYSTEM (and only falls back to ARCH if MSYSTEM is unset or unknown), then forwards ARCH to make-file-list.sh to learn which Pacman packages to install. On the UCRT64 git-sdk-64 (git-for-windows/git-sdk-64#117) the caller's MSYSTEM is UCRT64; today the script falls through to the *) default and ends up with MINGW_PREFIX=mingw64 and ARCH=x86_64, asking pacman for the long-gone mingw-w64-x86_64-* packages. Add a UCRT64 case alongside MINGW64 and CLANGARM64 that sets MINGW_PREFIX=ucrt64 and overrides ARCH=ucrt64 the same way CLANGARM64 overrides it to aarch64. make-file-list.sh, taught ARCH=ucrt64 in an earlier commit, then resolves the right Pacman package set. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

In git-for-windows/git-sdk-64#117, I am starting the MINGW64 -> UCRT64 migration, and therefore I want to target that branch, too, when uninstalling packages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

We are about to drop Windows 8.1 support, which allows us to switch from the MSVCRT-targeting MINGW64 flavor to the UCRT-targeting UCRT64. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

As per git-for-windows/git#6276, Git for Windows cannot _quite_ include the Rust bits yet. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Cherry-picked-from: e2602f5 (git-artifacts: opt out of the Rust bits for now, 2026-06-15) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This will make sure that this branch, which is destined to be integrated into `main` Real Soon Now, is in good shape. While at it, also add a `workflow_dispatch` trigger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This is required to build the Perl-related manual pages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Package creation fails in the generated SDK because the sparse selection still names `msys-crypto-1.1.dll`, omitting the `msys-crypto-3.dll` required by `bsdtar.exe`. Assisted-by: GPT-6 Astra Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Setting `MSYSTEM` alone did not supply the normal MinGW prefixes or select the SDK flavor. Auto-detection chose MINGW64, leaving installer dependencies missing; the unset package prefix broke MinGit's package query. PDB bundling requested MINGW64 symbols via the CPU label `x86_64`. The jobs need matching `MINGW_PREFIX` and `MINGW_PACKAGE_PREFIX` values and explicit UCRT64 selection for SDK creation and PDB bundling: the CPU architecture does not distinguish SDK flavors. This correction requires no changes to `build-extra` or the compiled Git packages. Assisted-by: GPT-6 Astra Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

apr-util (1.6.3-2 -> 1.6.5-1) bash (5.3.015-1 -> 5.3.015-2) bsdcpio (3.8.8-1 -> 3.8.9-1) bsdtar (3.8.8-1 -> 3.8.9-1) ca-certificates (20250419-1 -> 20260816-1) curl (8.21.0-1 -> 8.22.0-1) dos2unix (7.5.6-1 -> 7.5.7-1) expat (2.8.2-1 -> 2.8.4-1) findutils (4.10.0-3 -> 4.11.0-2) gnupg (2.4.9-1 -> 2.4.9-3) isl (0.27-1 -> 0.28-1) libarchive (3.8.8-1 -> 3.8.9-1) libcurl (8.21.0-1 -> 8.22.0-1) libexpat (2.8.2-1 -> 2.8.4-1) libffi (3.7.1-1 -> 3.8.0-1) libltdl (2.5.4-5 -> 2.6.2-1) libnghttp2 (1.69.0-1 -> 1.70.0-1) libp11-kit (0.26.4-1 -> 0.26.5-1) libpcre2_16 (10.47-1 -> 10.48-1) libpcre2_32 (10.47-1 -> 10.48-1) libpcre2_8 (10.47-1 -> 10.48-1) libpcre2posix (10.47-1 -> 10.48-1) libpsl (0.21.5-2 -> 0.23.2-1) libsqlite (3.53.3-1 -> 3.53.4-1) libtool (2.5.4-5 -> 2.6.2-1) lndir (1.0.5-1 -> 1.0.6-1) mingw-w64-ucrt-x86_64 (7zip-26.02-1 -> 7zip-26.03-1) mingw-w64-ucrt-x86_64-binutils (2.47-1 -> 2.47-3) mingw-w64-ucrt-x86_64-bzip2 (1.0.8-3 -> 1.0.8-4) mingw-w64-ucrt-x86_64-ca-certificates (20250419-1 -> 20260816-1) mingw-w64-ucrt-x86_64-crt (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-4) mingw-w64-ucrt-x86_64-curl-openssl-alternate (8.21.0-2 -> 8.22.0-1) mingw-w64-ucrt-x86_64-curl-winssl (8.21.0-2 -> 8.22.0-1) mingw-w64-ucrt-x86_64-expat (2.8.2-1 -> 2.8.4-2) mingw-w64-ucrt-x86_64-gcc (16.1.0-5 -> 16.2.0-3) mingw-w64-ucrt-x86_64-gcc-libs (16.1.0-5 -> 16.2.0-3) mingw-w64-ucrt-x86_64-git (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-credential-wincred (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-doc-html (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-for-windows-addons (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-gui (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-lfs (3.7.1-1 -> 3.8.0-1) mingw-w64-ucrt-x86_64-git-perl (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-send-email (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-subtree (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-git-svn (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-gitk (2.55.0.2-1 -> 2.55.0.5-1) mingw-w64-ucrt-x86_64-headers (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-2) mingw-w64-ucrt-x86_64-libffi (3.7.1-1 -> 3.8.0-1) mingw-w64-ucrt-x86_64-libmangle (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-2) mingw-w64-ucrt-x86_64-libsystre (1.0.2-2 -> 1.0.2-3) mingw-w64-ucrt-x86_64-libwinpthread (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-2) mingw-w64-ucrt-x86_64-openssl (3.6.3-1 -> 3.6.4-1) mingw-w64-ucrt-x86_64-osslsigncode (2.13-1 -> 2.14-1) mingw-w64-ucrt-x86_64-p11-kit (0.26.4-1 -> 0.26.5-1) mingw-w64-ucrt-x86_64-pcre2 (10.47-1 -> 10.48-3) mingw-w64-ucrt-x86_64-pkgconf (1~3.0.4-1 -> 1~3.0.7-1) mingw-w64-ucrt-x86_64-python (3.14.6-2 -> 3.14.7-1) mingw-w64-ucrt-x86_64-tools (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-2) mingw-w64-ucrt-x86_64-windows-default-manifest (6.4-4 -> 20260815-1) mingw-w64-ucrt-x86_64-winpthreads (14.0.0.r220.gd999af622-1 -> 14.0.0.r353.g6df76fa52-2) msys2-keyring (1~20260214-1 -> 1~20260814-1) nano (9.1-1 -> 9.2-1) openssh (10.4p1-1 -> 10.5p1-1) p11-kit (0.26.4-1 -> 0.26.5-1) pacman-contrib (1.10.6-1 -> 1.10.6-2) pcre2 (10.47-1 -> 10.48-1) perl (5.42.2-1 -> 5.42.3-1) perl-Authen-SASL (2.2000-1 -> 2.2100-1) perl-LWP-MediaTypes (6.04-2 -> 6.05-1) perl-MIME-tools (5.517-1 -> 5.518-1) perl-URI (5.35-1 -> 5.37-1) python (3.12.13-1 -> 3.12.14-1) rsync (3.4.4-1 -> 3.5.0-1) swig (4.4.0-1 -> 4.5.0-1) vim (9.2.0858-1 -> 9.2.0858-3) Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

dscho · 2026-09-09T17:43:28Z

Finally! The git-artifacts workflow was the last to fall, it is now also succeeding.

With the -rc0 looming tomorrow, I would like to merge this PR (via -s theirs) real soon now, maybe even tonight.

I kicked of a test run to ensure that Git for Windows' main builds and passes the test suite with this here PR branch, and another one to ensure that upstream Git's master does the same. The former already succeeded, and once the latter passes, I will prepare the merge commit.

To offer an escape hatch, I plan on offering the mingw64 pseudo-architecture in the setup-git-for-windows-sdk GitHub Action (I already pushed the mingw64 branch, currently identical to main, to this repository to prepare for that). Hopefully it won't actually be needed.

dscho · 2026-09-09T20:38:17Z

I kicked of a test run to ensure that Git for Windows' main builds and passes the test suite with this here PR branch, and another one to ensure that upstream Git's master does the same. The former already succeeded, and once the latter passes, I will prepare the merge commit.

Sadly, the latter failed. As this run demonstrates, gitgitgadget/git#2195 needs to be merged to upstream Git's master before it can build with a minimal UCRT64 flavor of Git for Windows' SDK.

I am seriously considering to skip updating the git-minimal-* files at https://github.com/git-for-windows/git-sdk-64/releases/ until upstream Git merges these patches down to master, just so that we can merge this here PR and switch to UCRT64 in time for -rc0.

Thoughts? Concerns?

With git-sdk-64/main moving to UCRT64, setup-git-for-windows-sdk needs a way to request the MINGW64 pseudo-architecture as a fallback without translating its architecture argument; for the full context see git-for-windows/git-sdk-64#117 Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

We're just about to "flip the switch", when Git for Windows' SDK will no longer be a MINGW64 one but a UCRT64 one, for full details see git-for-windows/git-sdk-64#117. Once that happens, we need `/ucrt64/bin/` to be in the `PATH` so that the `git.exe` is still found after that switch flip. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

As of git-for-windows/git-sdk-64#117, Git for Windows' SDK has migrated off of MINGW64 (which was deprecated by the MSYS2 project) onto UCRT64, leaving Windows 8.1 support behind. This GitHub Action needs to adapt to that migration. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

As git-for-windows/git-sdk-64#117 is now merged, Git for Windows' SDK has finally migrated off of MINGW64 (which was deprecated by the MSYS2 project) onto UCRT64, leaving Windows 8.1 support behind. This GitHub Action needs to adapt to that migration. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

mingw-w64-ucrt-x86_64-xz (5.8.3-1 -> 5.8.4-1) Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

This is the big commit switching Git for Windows' SDK over from MINGW64 to UCRT64. This has been long in the making, and required a ton of work, concluding #117. Here is the gist of it: MSYS2 deprecated MINGW64 a while back (for full details, see https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment); new MINGW64 packages are no longer accepted there, and updates of the ones we already ship have been winding down. The SDK has to move over to UCRT64 before what we ship starts to bit-rot. The migration was executed over the course of 3 months, starting by branching off `ucrt64` from `main` in git-sdk-64, kicking off the move to UCRT64 via a workflow that ran inside the PR, pulled in the UCRT64 equivalent of every MINGW64 package then-installed, and then removed the old MINGW64 and MINGW32 packages. Successively, packages for which UCRT64 equivalents did not exist were deployed to Git for Windows' Pacman repository at https://github.com/git-for-windows/pacman-repo/tree/x86_64/. Then Git for Windows' automation was extended to deploy UCRT64 variants of all the packages built for MINGW64, CLANGARM64 and MINGW32. The GitHub workflows in the `ucrt64` branch of git-sdk-64 were adapted so that they used and updated the correct parts of the SDK. The release automation was extended to release UCRT64 variants of all official versions. And now it is time: With this merge (which uses the `ours` merge strategy), all of the MINGW64/MINGW32 files in the `main` branch are replaced by their `ucrt64` equivalents. What a long journey! Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2026-09-10T13:38:52Z

I am seriously considering to skip updating the git-minimal-* files at https://github.com/git-for-windows/git-sdk-64/releases/ until upstream Git merges these patches down to master, just so that we can merge this here PR and switch to UCRT64 in time for -rc0.

I've ended up with a different strategy in git-for-windows/setup-git-for-windows-sdk#1454: hacking our way around the problem by detecting whether setup-git-for-windows-sdk is initialized via an upstream Git that cannot successfully build, and selecting MINGW64 instead of UCRT64 in that case.

Also, with 4177f7c I am going to go forward with the migration. Onward!

dscho self-assigned this Jun 6, 2026

dscho force-pushed the ucrt64 branch from 395beba to 63ffd01 Compare June 6, 2026 19:42

dscho force-pushed the ucrt64 branch from e50eec4 to cc279f3 Compare June 6, 2026 20:42

Git for Windows Build Agent added 3 commits June 6, 2026 20:45

dscho added 3 commits June 7, 2026 18:53

This was referenced Jun 7, 2026

Add ucrt64 architecture axis git-for-windows/setup-git-for-windows-sdk#1361

Merged

Prepare for building UCRT64 packages git-for-windows/build-extra#710

Merged

dscho force-pushed the ucrt64 branch 2 times, most recently from 0863902 to 927e526 Compare June 7, 2026 21:45

dscho mentioned this pull request Jun 8, 2026

drop-pacman-package: support MINGW packages and UCRT64 git-for-windows/git-for-windows-automation#176

Merged

dscho force-pushed the ucrt64 branch from 105d94d to 776eba7 Compare August 3, 2026 14:16

dscho added 3 commits August 31, 2026 14:52

git-artifacts: adapt to UCRT64

fdee642

We are about to drop Windows 8.1 support, which allows us to switch from the MSVCRT-targeting MINGW64 flavor to the UCRT-targeting UCRT64. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

git-artifacts: trigger on push to ucrt64

1be7efd

This will make sure that this branch, which is destined to be integrated into `main` Real Soon Now, is in good shape. While at it, also add a `workflow_dispatch` trigger. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho force-pushed the ucrt64 branch from 49eeb75 to 1be7efd Compare August 31, 2026 12:53

dscho added 3 commits September 9, 2026 11:52

git-artifacts: ensure that pod2man is on the PATH

37483e4

This is required to build the Perl-related manual pages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho deployed to sync September 9, 2026 16:52 — with GitHub Actions Active

dscho mentioned this pull request Sep 10, 2026

please.sh: accept --architecture=mingw64 in create_sdk_artifact git-for-windows/build-extra#739

Merged

Update 1 package

a016e1d

mingw-w64-ucrt-x86_64-xz (5.8.3-1 -> 5.8.4-1) Signed-off-by: Git for Windows Build Agent <ci@git-for-windows.build>

dscho mentioned this pull request Sep 10, 2026

Add the mingw64 pseudo architecture, and default to ucrt64 git-for-windows/setup-git-for-windows-sdk#1454

Merged

Navigation Menu

Uh oh!

Migrate the SDK from MINGW64 to UCRT64 - #117

Migrate the SDK from MINGW64 to UCRT64#117
dscho merged 46 commits into
mainfrom
ucrt64

dscho commented Jun 6, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 6, 2026

Uh oh!

dscho commented Jun 6, 2026

Uh oh!

dscho commented Jun 7, 2026

Uh oh!

dscho commented Sep 9, 2026

Uh oh!

dscho commented Sep 9, 2026

Uh oh!

dscho commented Sep 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

dscho commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 6, 2026

Uh oh!

dscho commented Jun 6, 2026

Uh oh!

dscho commented Jun 7, 2026

Uh oh!

dscho commented Sep 9, 2026

Uh oh!

dscho commented Sep 9, 2026

Uh oh!

dscho commented Sep 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dscho commented Jun 6, 2026 •

edited

Loading