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>
There seems to be some internal stack overflow detection in MSVC's
`malloc()` machinery that seems to be independent of the `stack reserve`
and `heap reserve` sizes specified in the executable (editable via
`EDITBIN /STACK:<n> <exe>` and `EDITBIN /HEAP:<n> <exe>`).
In the newly test cases added by `jk/tree-name-and-depth-limit`, this
stack overflow detection is unfortunately triggered before Git can print
out the error message about too-deep trees and exit gracefully. Instead,
it exits with `STATUS_STACK_OVERFLOW`. This corresponds to the numeric
value -1073741571, something the MSYS2 runtime we sadly need to use to
run Git's test suite cannot handle and which it internally maps to the
exit code 127. Git's test suite, in turn, mistakes this to mean that the
command was not found, and fails both test cases.
Here is an example stack trace from an example run:
[0x0] ntdll!RtlpAllocateHeap+0x31 0x4212603f50 0x7ff9d6d4cd49
[0x1] ntdll!RtlpAllocateHeapInternal+0x6c9 0x42126041b0 0x7ff9d6e14512
[0x2] ntdll!RtlDebugAllocateHeap+0x102 0x42126042b0 0x7ff9d6dcd8b0
[0x3] ntdll!RtlpAllocateHeap+0x7ec70 0x4212604350 0x7ff9d6d4cd49
[0x4] ntdll!RtlpAllocateHeapInternal+0x6c9 0x42126045b0 0x7ff9596ed480
[0x5] ucrtbased!heap_alloc_dbg_internal+0x210 0x42126046b0 0x7ff9596ed20d
[0x6] ucrtbased!heap_alloc_dbg+0x4d 0x4212604750 0x7ff9596f037f
[0x7] ucrtbased!_malloc_dbg+0x2f 0x42126047a0 0x7ff9596f0dee
[0x8] ucrtbased!malloc+0x1e 0x42126047d0 0x7ff730fcc1ef
[0x9] git!do_xmalloc+0x2f 0x4212604800 0x7ff730fcc2b9
[0xa] git!do_xmallocz+0x59 0x4212604840 0x7ff730fca779
[0xb] git!xmallocz_gently+0x19 0x4212604880 0x7ff7311b0883
[0xc] git!unpack_compressed_entry+0x43 0x42126048b0 0x7ff7311ac9a4
[0xd] git!unpack_entry+0x554 0x42126049a0 0x7ff7311b0628
[0xe] git!cache_or_unpack_entry+0x58 0x4212605250 0x7ff7311ad3a8
[0xf] git!packed_object_info+0x98 0x42126052a0 0x7ff7310a92da
[0x10] git!do_oid_object_info_extended+0x3fa 0x42126053b0 0x7ff7310a44e7
[0x11] git!oid_object_info_extended+0x37 0x4212605460 0x7ff7310a38ba
[0x12] git!repo_read_object_file+0x9a 0x42126054a0 0x7ff7310a6147
[0x13] git!read_object_with_reference+0x97 0x4212605560 0x7ff7310b4656
[0x14] git!fill_tree_descriptor+0x66 0x4212605620 0x7ff7310dc0a5
[0x15] git!traverse_trees_recursive+0x3f5 0x4212605680 0x7ff7310dd831
[0x16] git!unpack_callback+0x441 0x4212605790 0x7ff7310b4c95
[0x17] git!traverse_trees+0x5d5 0x42126058a0 0x7ff7310dc0f2
[0x18] git!traverse_trees_recursive+0x442 0x4212605980 0x7ff7310dd831
[0x19] git!unpack_callback+0x441 0x4212605a90 0x7ff7310b4c95
[0x1a] git!traverse_trees+0x5d5 0x4212605ba0 0x7ff7310dc0f2
[0x1b] git!traverse_trees_recursive+0x442 0x4212605c80 0x7ff7310dd831
[0x1c] git!unpack_callback+0x441 0x4212605d90 0x7ff7310b4c95
[0x1d] git!traverse_trees+0x5d5 0x4212605ea0 0x7ff7310dc0f2
[0x1e] git!traverse_trees_recursive+0x442 0x4212605f80 0x7ff7310dd831
[0x1f] git!unpack_callback+0x441 0x4212606090 0x7ff7310b4c95
[0x20] git!traverse_trees+0x5d5 0x42126061a0 0x7ff7310dc0f2
[0x21] git!traverse_trees_recursive+0x442 0x4212606280 0x7ff7310dd831
[...]
[0xfad] git!cmd_main+0x2a2 0x42126ff740 0x7ff730fb6345
[0xfae] git!main+0xe5 0x42126ff7c0 0x7ff730fbff93
[0xfaf] git!wmain+0x2a3 0x42126ff830 0x7ff731318859
[0xfb0] git!invoke_main+0x39 0x42126ff8a0 0x7ff7313186fe
[0xfb1] git!__scrt_common_main_seh+0x12e 0x42126ff8f0 0x7ff7313185be
[0xfb2] git!__scrt_common_main+0xe 0x42126ff960 0x7ff7313188ee
[0xfb3] git!wmainCRTStartup+0xe 0x42126ff990 0x7ff9d5ed257d
[0xfb4] KERNEL32!BaseThreadInitThunk+0x1d 0x42126ff9c0 0x7ff9d6d6aa78
[0xfb5] ntdll!RtlUserThreadStart+0x28 0x42126ff9f0 0x0
I verified manually that `traverse_trees_cur_depth` was 562 when that
happened, which is far below the 2048 that were already accepted into
Git as a hard limit.
Despite many attempts to figure out which of the internals trigger this
`STATUS_STACK_OVERFLOW` and how to maybe increase certain sizes to avoid
running into this issue and let Git behave the same way as under Linux,
I failed to find any build-time/runtime knob we could turn to that
effect.
Note: even switching to using a different allocator (I used mimalloc
because that's what Git for Windows uses for its GCC builds) does not
help, as the zlib code used to unpack compressed pack entries _still_
uses the regular `malloc()`. And runs into the same issue.
Note also: switching to using a different allocator _also_ for zlib code
seems _also_ not to help. I tried that, and it still exited with
`STATUS_STACK_OVERFLOW` that seems to have been triggered by a
`mi_assert_internal()`, i.e. an internal assertion of mimalloc...
So the best bet to work around this for now seems to just lower the
maximum allowed tree depth _even further_ for MSVC builds.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
We have `ci/install-dependencies.sh` for that. Incidentally, this avoids
the following error in the linux-* jobs:
The following packages have unmet dependencies:
git-email : Depends: git (< 1:2.25.1-.) but 1:2.35.1-0ppa1~ubuntu20.04.1 is to be installed
Recommends: libemail-valid-perl but it is not going to be installed
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
