✨ Migrating away from $BITNESS in favor of architecture names

[dennisameling]

Historically, Git for Windows has been using the $BITNESS variable in quite a few places in its tooling. It was used for things like:

• indicating the MINGW prefix (e.g. /mingw$BITNESS would resolve to /mingw32 and mingw64)
• defining release artifact names like Git-2.39.0.2-$BITNESS-bit.exe and PortableGit-2.39.0.2-$BITNESS-bit.7z.exe.

This was helpful, because Git for Windows has been supporting both 32-bit (x86) and 64-bit (amd64) Windows for quite a while.

However, now that arm64 is coming into the mix, this approach no longer works. After some discussion on how to move forward, it was decided to use the following naming for the various architectures:

• x86
• amd64
• arm64

This has implications for multiple aspects of Git for Windows's tooling and artifacts. This discussion aims to provide clarity on when to use which names.

Artifact names

The will be a transition period for the new artifact names, as some downstream projects depend on Git for Windows having certain artifact names. Git for Windows will publish binaries both with the old and the new names for the next two releases after 2.39.0. This means that a single GitHub release will contain both artifact names, which are the exact same binaries in the background.

The transition period mentioned above is preliminary and might be changed if there are any blockers in the release process.

Before	After
Git-2.39.0-64-bit.exe	Git-2.39.0-amd64.exe
Git-2.39.0-32-bit.exe	Git-2.39.0-x86.exe
n/a	Git-2.39.0-arm64.exe
PortableGit-2.39.0-64-bit.7z.exe	PortableGit-2.39.0-amd64.7z.exe
PortableGit-2.39.0-32-bit.7z.exe	PortableGit-2.39.0-x86.7z.exe
n/a	PortableGit-2.39.0-arm64.7z.exe

MINGW prefixes

/mingw$BITNESS can no longer be used as the prefix for arm64 is /clangarm64. A different approach is needed.

In most cases, you can use the predefined $MINGW_PREFIX. It resolves to /mingw32, /mingw64 and /clangarm64, which is consistent with MSYS2's environment naming. Whenever an $MSYSTEM is set in the shell (which is true when using the setup-git-for-windows GitHub action for example), you can expect $MSYSTEM_PREFIX to be set as well. Please double-check this in your scripts.

Pacman

This affects all packages that start with mingw-w64-*. As Git for Windows uses the same Pacman package names as upstream MSYS2, no major changes are needed here. Use the predefined $MINGW_PACKAGE_PREFIX whenever possible. It resolves to mingw-w64-x86_64, mingw-w64-i686 and mingw-w64-clang-aarch64.

Note that MSYS2 uses aarch64 and clang-aarch64 for package names. This means that Pacman packages are the only exception to the architectures mentioned at the beginning of this post (amd64, x86, arm64).

A new Pacman repository has been created for arm64, meaning the list of Git for Windows's repositories now looks as follows:

[git-for-windows]
Server = https://wingit.blob.core.windows.net/x86-64

[git-for-windows-mingw32]
Server = https://wingit.blob.core.windows.net/i686

[git-for-windows-aarch64]
Server = https://wingit.blob.core.windows.net/aarch64

SDKs

The Git for Windows SDKs will be renamed to be in line with the architectures mentioned at the beginning of this discussion:

Before	After
git-sdk-64	git-sdk-amd64
git-sdk-32	git-sdk-x86
n/a	git-sdk-arm64

Please let us know if you have any questions or feedback about this! ✨

CC @dscho @rimrul

[dscho]

Hmm. I am still not quite happy with deviating so much from MSYS2, at least when it comes to tooling. The end-user facing artifacts, sure, I get that Git-2.39.1-amd64.exe is nicer to read than Git-2.39.1-x86_64.exe. But my mind stumbles over architecture: amd64 for setup-git-for-windows-sdk when all we do there is downloading x86_64 packages, not arm64 ones.

[dennisameling]

@dscho I wasn't planning on changing the architecture: amd64 input in setup-git-for-windows-sdk. Also see git-for-windows/git-for-windows-automation#22 which passes the architecture (x86_64 or i686 for now) directly to setup-git-for-windows-sdk. The change was only related to the repo name: e.g. git-sdk-64 to git-sdk-amd64. Or am I misunderstanding something here? Thanks!

[dscho]

My concern comes from git-for-windows/build-extra#462. It changes how please.sh create-sdk-artifact works, which is the work horse of setup-git-for-windows-sdk.

[dennisameling]

Ah, good catch. My bad. I've just updated that PR to use x86_64, i686 and aarch64 instead. Thanks!

[dennisameling]

@dscho assuming that we'll finally get some stable ARM64 pipelines soon, I'd like to revive this discussion around the naming of the architectures. I'd like to specifically discuss the release artifact names.

May I suggest the following three-step approach:

1. Update the release pipeline for x64/x86 to provide release binaries with the new suffixes (e.g. Git-2.45.0-amd64.exe instead of Git-2.45.0-64-bit.exe). Then, to facilitate a temporary transition period for users, duplicate those binaries in the script to also release them under the old names. So same file, different name. That way, if folks have set up automated scripts to download new Git for Windows versions, those won't break.
2. When we're ready, add ARM64 versions to the release binaries as well.
3. At some point in the future, stop releasing the x64/x86 artifacts under their old names.

I'd be happy to update the release scripts, and will go with whatever suffixes you prefer (amd64, x86_64, etc.).

WDYT?

[dscho]

After thinking about this for a good while, I think that I would prefer to keep calling the x86_64 installer -64-bit and the i686 installer -32-bit. I agree that it is sub-optimal, but I simply do not see any non-disruptive way to rename the artifacts or the git-sdk-* repositories.

Maybe a note in each GitHub Release's description ("Note: For historical reasons, the artifacts for Intel/AMD have a -64-bit/-32-bit suffix while the artifacts for ARM have the more descriptive -arm64 suffix") would be enough of a compromise?