**This requires an ARM64-machine with Windows 11 installed (which
supports x64 emulation for MSYS2)**
### The main idea
- Use the main MSYS2/git-sdk-64 setup, which works on Windows 11 on ARM
thanks to x64-emulation
- Configure the official `clangarm64` MSYS2 repo
- Install `mingw-w64-clang-aarch64-toolchain` which contains the
ARM64-native Clang compiler
Add `FileVersion`, which is a required string ([Microsoft
documentation](https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource))
in the `StringFileInfo` block.
As not all required strings were present in the block, none were being
included.
Fixes#4090
After including the `FileVersion` string, all other defined strings are
now being included on executables.
File version information for `git.exe` has changed from:
```
PS C:\Program Files\Git\bin> [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Data\git-sdk-64\usr\src\git\git.exe") | Select-Object *
FileVersionRaw : 2.38.1.1
ProductVersionRaw : 2.38.1.1
Comments :
CompanyName :
FileBuildPart : 1
FileDescription :
FileMajorPart : 2
FileMinorPart : 38
FileName : C:\Data\git-sdk-64\usr\src\git\git.exe
FilePrivatePart : 1
FileVersion :
InternalName :
IsDebug : False
IsPatched : False
IsPrivateBuild : False
IsPreRelease : False
IsSpecialBuild : False
Language : English (United States)
LegalCopyright :
LegalTrademarks :
OriginalFilename :
PrivateBuild :
ProductBuildPart : 1
ProductMajorPart : 2
ProductMinorPart : 38
ProductName :
ProductPrivatePart : 1
ProductVersion :
SpecialBuild :
```
To the following:
```
PS C:\Program Files\Git\bin> [System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Data\git-sdk-64\usr\src\git\git.exe") | Select-Object *
FileVersionRaw : 2.38.1.1
ProductVersionRaw : 2.38.1.1
Comments :
CompanyName : The Git Development Community
FileBuildPart : 1
FileDescription : Git for Windows
FileMajorPart : 2
FileMinorPart : 38
FileName : C:\Data\git-sdk-64\usr\src\git\git.exe
FilePrivatePart : 1
FileVersion : 2.38.1.windows.1.10.g6ed65a6fab
InternalName : git
IsDebug : False
IsPatched : False
IsPrivateBuild : False
IsPreRelease : False
IsSpecialBuild : False
Language : English (United States)
LegalCopyright :
LegalTrademarks :
OriginalFilename : git.exe
PrivateBuild :
ProductBuildPart : 1
ProductMajorPart : 2
ProductMinorPart : 38
ProductName : Git
ProductPrivatePart : 1
ProductVersion : 2.38.1.windows.1.10.g6ed65a6fab
SpecialBuild :
```
I wasn't really expecting `GIT_VERSION` to contain the Git commit, I was
hoping for just `2.38.1` or `2.38.1.1`, at least for the `FileVersion`
string.
Anybody know if it's possible to concatenate the `MAJOR`, `MINOR`,
`MICRO`, and `PATCHLEVEL` fields with dots, or if there's another
variable that can be used (with or without `PATCHLEVEL`)?
Alternatively, use the complete `GIT_VERSION` for both `FileVersion` and
`ProductVersion`.
Backport a couple fixes to make the CI build run again (so much for
reproducible builds...).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The first three commits are rebased versions of those in gitgitgadget/git#1215. These allow the following:
1. Fix `git config --global foo.bar <path>` from allowing the `<path>`. As a bonus, users with a config value starting with `/` will not get a warning about "old-style" paths needing a "`%(prefix)/`".
2. When in WSL, the path starts with `/` so it needs to be interpolated properly. Update the warning to include `%(prefix)/` to get the right value for WSL users. (This is specifically for using Git for Windows from Git Bash, but in a WSL directory.)
3. When using WSL, the ownership check fails and reports an error message. This is noisy, and happens even if the user has marked the path with `safe.directory`. Remove that error message.
Even if CMake is not the canonical way to build Git for Windows, but
CMake support merely exists in Git to support building Git for Windows
using Visual Studio, we should include `headless-git` in such a scenario
when installing the binaries to a given location.
This merges the current version of the patch that tries to address Git
GUI's problems with intent-to-add files.
This patch will likely be improved substantially before it is merged
into Git GUI's main branch, but we want to have _something_ resembling a
fix already in Git for Windows v2.29.0.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch allows `add -p` and `add -i` with a large number of
files. It is kind of a hack that was never really meant to be
upstreamed. Let's see if we can do better in the built-in `add -p`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic vendors in mimalloc v2.0.9, a fast allocator that allows Git
for Windows to perform efficiently.
Switch Git for Windows to using mimalloc instead of nedmalloc
In MSYS2, we have two Python interpreters at our disposal, so we can
include the Python stuff in the build.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch teaches `git clean` to respect NTFS junctions and Unix
bind mounts: it will now stop at those boundaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch allows us to specify absolute paths without the drive
prefix e.g. when cloning.
Example:
C:\Users\me> git clone https://github.com/git/git \upstream-git
This will clone into a new directory C:\upstream-git, in line with how
Windows interprets absolute paths.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These fixes were necessary for Sverre Rabbelier's remote-hg to work,
but for some magic reason they are not necessary for the current
remote-hg. Makes you wonder how that one gets away with it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch extends the protections introduced for Git GUI's
CVE-2022-41953 to cover `gitk`, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As reported in https://lore.kernel.org/git/ZuPKvYP9ZZ2mhb4m@pks.im/,
libcurl v8.10.0 had a regression that was picked up by Git's t5559.30
"large fetch-pack requests can be sent using chunked encoding".
This bug was fixed in libcurl v8.10.1.
Sadly, the macos-13 runner image was updated in the brief window between
these two libcurl versions, breaking each and every CI build, as
reported at https://github.com/git-for-windows/git/issues/5159.
This would usually not matter, we would just ignore the failing CI
builds until the macos-13 runner image is rebuilt in a couple of days,
and then the CI builds would succeed again.
However.
As has become the custom, a surprise Git version was released, and now
that Git for Windows wants to follow suit, since Git for Windows has
this custom of trying to never release a version with a failing CI
build, we _must_ work around it.
This patch implements this work-around, basically for the sake of Git
for Windows v2.46.2's CI build.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CLANGARM64 is a relatively new MSYSTEM added by the MSYS2 team. In order
to have Git build correctly for this platform, let's add some
configuration for it to config.mak.uname.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Newer compiler versions, like GCC 10 and Clang 12, have built-in
functions for bswap32 and bswap64. This comes in handy, for example,
when targeting CLANGARM64 on Windows, which would not be supported
without this logic.
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Add FileVersion, which is a required field
As not all required fields were present, none were being included
Fixes#4090
Signed-off-by: Kiel Hurley <kielhurley@gmail.com>
Whith Windows 2000, Microsoft introduced a flag to the PE header to mark executables as
"terminal server aware". Windows terminal servers provide a redirected Windows directory and
redirected registry hives when launching legacy applications without this flag set. Since we
do not use any INI files in the Windows directory and don't write to the registry, we don't
need this additional preparation. Telling the OS that we don't need this should provide
slightly improved startup times in terminal server environments.
When building for supported Windows Versions with MSVC the /TSAWARE linker flag is
automatically set, but MinGW requires us to set the --tsaware flag manually.
This partially addresses https://github.com/git-for-windows/git/issues/3935.
Signed-off-by: Matthias Aßhauer <mha1993@live.de>
This is inspired by d051ed77ee (.github/workflows/main.yml: run
static-analysis on bionic, 2021-02-08) and by ef46584831 (ci: update
'static-analysis' to Ubuntu 22.04, 2022-08-23), adapted to the Azure
Pipeline.
When Azure Pipelines' build agents transitioned 'ubuntu-latest' from
18.04 to 20.04, it broke our `static-analysis` job, since Coccinelle
was not madeavailable on Ubuntu focal (it is only available in the
universe suite).
This is not an issue with Ubuntu 22.04, but we will only know whether it
is an issue with 24.04 when _that_ comes out. So let's play it safe and
pin the `static_analysis` job to the latest Ubuntu version that we know
to offer a working Coccinelle package.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
