Prepare the git-extra package for UCRT64#711
Merged
Merged
Conversation
mjcheetham
approved these changes
Jun 9, 2026
mjcheetham
left a comment
Member
There was a problem hiding this comment.
As part of this effort, we drop the prefix-less git-extra package at long last
I do love myself some consistency :-)
Member
Author
|
We probably need to patch |
Originally, `git-extra` was the package name, even if strictly speaking it is a MINGW package and therefore should have the `mingw-w64-<arch>-` package prefix (also known as `MINGW_PACKAGE_PREFIX`). However, this prefix only exists, really, to allow MINGW packages of different architectures to be installed side-by-side (the same is not possible for MSYS packages, as they share a single MSYS2 runtime). And the `git-extra` package shares that trait with MSYS packages: You cannot install it side-by-side for different architectures. There is, however, a really good reason to enforce this package prefix _now_: Git for Windows is migrating from MINGW64 to UCRT64 (because the former has been deprecated by the MSYS2 project). Therefore we need to build `git-extra` for both, _and host them in the same Pacman repository_. So let's drop the old name, at long last. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The fact that both `git-extra.install.in` and `git-extra.install` were tracked in Git was always a wart. The reason for that was that `makepkg-mingw` would complain if that file did not exist, because it was defined via the `install` directive, even if the build would eventually generate it. Use a cunning trick to circumvent that: Move the `install` directive into the `package` function so that it is _not_ defined right after sourcing `PKGBUILD`, and the linter won't complain. It is only needed for packaging anyway, so that's the right layer to define it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The dashed Git commands have been deprecated for a ridiculously long time, and Git for Windows does not even install them anymore. However, there _is_ handling for them in the post-install script of the `git-extra` package. Naturally, this logic needs to look at paths in the $MINGW_PREFIX namespace. Previously, there was an awkward loop that wanted to look over all of the supported architectures. That was necessary because the actual, current architecture could not be hard-coded in `git-extra.install` because it was tracked in Git and it needed to apply to all the MINGW_ARCH values for which the package could ever be built. However, now that we use a better strategy where `git-extra.install` does _not_ need to be tracked, we can totally do the right thing and hard-code that architecture in `git-extra.install`. This commit is best viewed with `-w`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git's deprecated dashed commands are no longer built by Git for Windows. They should also no longer be "replaced" by the `git-extra` package's post-install script. However, the check added in 62dcef7 (git-extra: fix up Git's builtins, 2016-08-29) that was supposed to detect the absence of the dashed commands keyed on a dashed command that _does_ need to exist, for historical warts reasons: It is called in the dashed form by any `git push` via SSH. Let's fix that check so that it keys on a dashed command that is actually absent these days. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that we have a good strategy that allows architecture-specific `git-extra.install` files, let's no longer play run-time `uname -m` check games anymore. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that `git-extra.install` is generated, it can hard-code at build-time whether or not to add the aarch64 Pacman repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Earlier, this was a run-time check. But now we can hard-code the correct architecture at build-time. This prepares for UCRT64 and incidentally also addresses a warning when installing in a CLANGARM64 setup. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The pthread header needs a fix that we apply in git-extra's post-install script. However, it hard-coded the MINGW* variants of the header, when we really need something much more general. This most likely fixes an existing issue in CLANGARM64, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is _unlikely_ that we're going to move it _again_, but just in case... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Yet another tiny step to migrating from MINGW64 to UCRT64... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With all these preparations for UCRT64 in place, it is time to deploy a new release. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This comment was marked as outdated.
This comment was marked as outdated.
Member
Author
|
/deploy git-extra The i686/x86_64 and the arm64 workflow runs were started. |
pull Bot
pushed a commit
to frikke/git-for-windows-automation
that referenced
this pull request
Jun 17, 2026
In git-for-windows/build-extra#711 I am preparing the `git-extra` package for the MINGW64 -> UCRT64 migration. Once that lands, the natural next step is to actually build the UCRT64 variants of the affected packages via this workflow, and for that the workflow has to know about UCRT64. The `setup-git-for-windows-sdk` action already accepts `ucrt64` as a value for its `architecture` input (which installs the UCRT64 variant of git-sdk-64), so let's reuse the same spelling as a pseudo architecture here: the runner is still `windows-latest` (UCRT64 is just an alternative MSYS2 environment on x86_64), `git.exe` is looked up under `/ucrt64/bin/`, and `MINGW_ARCH=ucrt64` is passed to `makepkg-mingw`. The `BUILD_SRC` flag stays empty, just like for `i686` and `aarch64`, because building the `.src.tar.gz` for the x86_64 variant of a package (should it also be built) already covers what would otherwise be produced for ucrt64. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
git-extrapackage is quite central to Git for Windows' ecosystem, as it ships a few tools that are specific to this project, and it also adapts a few of MSYS2's configurations via the post-install script that cannot be adapted otherwise.To accommodate for the migration from MINGW64 to UCRT64, we need to adapt this central package, in particular said post-install script.
As part of this effort, we drop the prefix-less
git-extrapackage at long last: It now must be installed using themingw-w64-<arch>-git-extraname.Note: Even though we now have a
git-for-windows-ucrt64.dbPacman package database, this PR does not actually need it (except for deploying), as all the UCRT64 packages are naturally included in thegit-for-windows-x86_64.dbdatabase anyway. The git-sdk-32 and git-sdk-arm64 repositories still reference the MINGW-onlygit-for-windows-mingw64.dbdatabase, for now.