Skip to content

Prepare the git-extra package for UCRT64#711

Merged
dscho merged 13 commits into
mainfrom
git-extra-ucrt64
Jun 16, 2026
Merged

Prepare the git-extra package for UCRT64#711
dscho merged 13 commits into
mainfrom
git-extra-ucrt64

Conversation

@dscho

@dscho dscho commented Jun 9, 2026

Copy link
Copy Markdown
Member

The git-extra package 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-extra package at long last: It now must be installed using the mingw-w64-<arch>-git-extra name.

Note: Even though we now have a git-for-windows-ucrt64.db Pacman package database, this PR does not actually need it (except for deploying), as all the UCRT64 packages are naturally included in the git-for-windows-x86_64.db database anyway. The git-sdk-32 and git-sdk-arm64 repositories still reference the MINGW-only git-for-windows-mingw64.db database, for now.

@dscho dscho requested review from mjcheetham and rimrul June 9, 2026 11:43
@dscho dscho self-assigned this Jun 9, 2026

@mjcheetham mjcheetham left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As part of this effort, we drop the prefix-less git-extra package at long last

I do love myself some consistency :-)

@dscho

dscho commented Jun 9, 2026

Copy link
Copy Markdown
Member Author

We probably need to patch build-and-deploy.yml (at least here and here) and slash-commands.js before using /deploy...

dscho added 13 commits June 16, 2026 12:25
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>
@dscho

This comment was marked as outdated.

@dscho

dscho commented Jun 16, 2026

Copy link
Copy Markdown
Member Author

/deploy git-extra

The i686/x86_64 and the arm64 workflow runs were started.

@dscho dscho merged commit 5031c64 into main Jun 16, 2026
10 checks passed
@dscho dscho deleted the git-extra-ucrt64 branch June 16, 2026 16:04
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants