ARM64 (aarch64/ARMv7) on Windows 10: sh.exe "not compatible with the version of Windows you're running"

[MikeFarrington]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.47.1.windows.1
cpu: aarch64
built from commit: 2cd22437f64229935dc564db969cbcbfed5e9045
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-arm64-build-installers/usr/bin/sh          <------ this is weird, not a drive or folder on my system
feature: fsmonitor--daemon
libcurl: 8.11.0
OpenSSL: OpenSSL 3.2.3 3 Sep 2024
zlib: 1.3.1

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 10 (22H2) on 64-bit ARMv7 (Qualcomm Snapdragon 835 CPU)

Microsoft Windows [Version 10.0.19045.5198]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Mostly defaults. VSCode for GUI, REBASE by default

Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Git Pull Behavior Option: Rebase
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I am running an older ARM on Windows CPU which isn't getting official Windows 11 support from Microsoft but still works well with just about every natively compiled application for Windows on ARM.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

I've tried both CMD and PowerShell. Bash will not launch due to error being reported.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

.\sh.exe
git fetch

• What did you expect to occur after running these commands?

Git to work as expected, without throwing errors about the version of Windows

• What actually happened instead?

PS C:\Program Files\Git\bin> .\sh.exe
error launching git: This version of %1 is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.

PS C:\MyGitProjectFolder> git fetch
error: cannot spawn C:/Program Files/Git/usr/bin/sh.exe: Function not implemented
error: cannot spawn bash: Function not implemented
fatal: could not read Username for 'https://github.com': No such file or directory

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

Not related to repository

[dscho]

This is sadly expected. Windows 10 only runs i686 code (also known as x86, i.e. 32-bit AMD/Intel) in emulation, and not x86_64 (also known as x64, i.e. 64-bit AMD/Intel). However, for technical reasons Git Bash does not yet support Windows/ARM64 natively.

I tried to clarify this in this comment.

[MikeFarrington]

This is sadly expected. Windows 10 only runs i686 code (also known as x86, i.e. 32-bit AMD/Intel) in emulation, and not x86_64 (also known as x64, i.e. 64-bit AMD/Intel). However, for technical reasons Git Bash does not yet support Windows/ARM64 natively.

I tried to clarify this in this comment.

Ah, that explains it. I wonder if the x86/32-bit bash shell should be included for the very few like me who still have these ARMv7 WOA computers in the wild (since there is no upgrade path to Windows 11 w/amd64 WoW emulation)? I know Git for Windows is looking to drop x86 support overall, but maybe this one component can live on in the arm64 package until it has a natively compiled version available.

There's so few of us though that it's probably not worth the effort. Basically, only a handful of Asus NovaGo owners who also happen to use Git.

Unfortunately, the x86 version isn't working under emulation. It just sort of hangs and does nothing on a 'git fetch'.

[dscho]

While I am sympathetic, I can indeed not justify working on it. But I can give you pointers to get started:

• you could start by extracting Portable-Git-32-bit,
  • then removing its mingw32 folder and replacing it with the clangarm64 folder of Portable-Git-arm64,
  • then starting Git Bash
  • then adjust PATH by replacing mingw32 with clangarm64 in it.

A "full" solution would be much more involved, and would assume that you can use git clone from Portable-Git-arm64. The strategy would then be to:

• fork git-sdk-32,
• clone it,
• start a Git SDK Bash by launching the git-bash.exe contained in the top-level directory of that worktree
• remove all mingw-w64-i686-* packages from it via pacman -R <package>...,
• add the clangarm64 Pacman repository by editing /etc/pacman.conf,
• install the `mingw-w64-clang-aarch64-* versions of the just-removed packages,
• re-run git-bash.exe so that the PATH includes /clangarm64/bin/,
• publish the fork,
• work out all the kinks 😉

[dscho]

Unfortunately, the x86 version isn't working under emulation. It just sort of hangs and does nothing on a 'git fetch'.

This is a bit worrisome, as the same root cause may potentially prevent a lot of Git Bash's stuff to work, anyway, in which case all of the effort to get it to run would be in vain.

[jeremyd2019]

I was thinking about this too, but figured it was a small enough userbase to not be worth it. Did you backport the hang fix to your i686 msys2-runtime-3.3 fork here?

Maybe you could add a check to block install on Windows 10 to the ARM64 installer if you don't want to support it?

[dscho]

Did you backport the hang fix to your i686 msys2-runtime-3.3 fork here?

No... But I'd gladly accept a PR (@MikeFarrington hint, hint😀 )

Maybe you could add a check to block install on Windows 10 to the ARM64 installer if you don't want to support it?

Sure, but I do not want to invest energy in preventing something that highly interested & motivated users may still bring about.

[jeremyd2019]

Maybe you could add a check to block install on Windows 10 to the ARM64 installer if you don't want to support it?

Sure, but I do not want to invest energy in preventing something that highly interested & motivated users may still bring about.

It seems to me that the small percentage of ARM64 users who need i686 MSYS2 wouldn't be worth switching ARM64 entirely over to i686 (with its issues including lack of upstream support and address space conflicts), so if somebody did make an i686+ARM64 version, it would probably be a different installer than the x86_64+ARM64 one (which would still not work properly on Windows 10).

[jeremyd2019]

Did you backport the hang fix to your i686 msys2-runtime-3.3 fork here?

No... But I'd gladly accept a PR (@MikeFarrington hint, hint😀 )

If you don't know what I'm talking about, it's https://github.com/msys2/msys2-runtime/compare/bb6258c..fbc1019 (but it looks like 1f3be1e on are not in git-for-windows/msys2-runtime's 3.3 branch)