Apparently my tests of https://github.com/git-for-windows/git/pull/5586
had been incomplete. This here patch is needed to let t0060.221 pass
(where it verifies that `git.exe` sets `MSYSTEM` correctly if that
environment variable has not yet been set): Simply reverse the order of
the tests whether to set `MINGW64` or `CLANGARM64` to avoid using the
former on Windows/ARM64 by mistake.
This patch makes it so that Git really sets the desired `MSYSTEM` on
Windows/ARM64.
The reason this did not work (and my faulty tests did not catch that
before merging https://github.com/git-for-windows/git/pull/5586) is that
clang (at least version 20.1.3 as built from
https://github.com/git-for-windows/MINGW-packages
8df0c2fff4184deff15acce9bfd791fb6e0d60fe) predefines the `__MINGW64__`
constant:
$ echo | clang -dM -E - | grep -n MINGW64
249:#define __MINGW64__ 1
Let's just switch the order between the CLANGARM64 and the MINGW64 test;
This will still work for MINGW64 because none of the constants used in
the CLANGARM64 condition are defined for x64 gcc (or for that matter,
clang).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I encountered these issues that had hitherto escaped us [when I worked
on letting the `ci-artifacts` workflow in git-sdk-arm64 also build Git
and run the test
suite](https://github.com/git-for-windows/git-sdk-arm64/pull/37) by way
of validating the `minimal-sdk` artifact.
Mind, this PR does not only adjust a test case that was previously too
fixated on x86_64. There are two real issues that this PR addresses and
that were found via the test suite:
- When the environment variable `MSYSTEM` is not yet set, it now is set
appropriately even on Windows/ARM64 (and the `PATH` is adjusted
accordingly).
- The tree traversal limit designed to avoid stack overflows needed to
be adjusted for the clangarm64 builds.
Just as in b64d78ad02 (max_tree_depth: lower it for MSVC to avoid
stack overflows, 2023-11-01), I encountered the same problem with the
clang builds on Windows/ARM64.
The symptom is an exit code 127 when t6700 tries to verify that `git
archive big` fails.
This exit code is reserved on Unix/Linux to mean "command not found".
Unfortunately in this case, it is the fall-back chosen by
Cygwin's `pinfo::status_exit()` method when encountering
the NSTATUS `STATUS_STACK_OVERFLOW`, see
https://github.com/cygwin/cygwin/blob/cygwin-3.6.1/winsup/cygwin/pinfo.cc#L171
I verified manually that the stack overflow always happens somewhere
around tree depth 1403, therefore 1280 should be a safe bound in these
instances.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's ignore the `static void mi_stat_total_print()` function that is
not actually used. This is code vendored into Git, and we want to
deviate as minimally from upstream mimalloc as possible to make it cheap
to stay up to date.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To support mimalloc-enabled builds also on Linux and on macOS, we need
to ship the respective backends, too.
This helped me diagnose "mimalloc vs reftable" problems much quicker
because Git's birthplace *is* Linux, and its support for debugging on
that platform is still highly unmatched by its support for any other
platform.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We want to compile mimalloc's source code as part of Git, rather than
requiring the code to be built as an external library: mimalloc uses a
CMake-based build, which is not necessarily easy to integrate into the
flavors of Git for Windows (which will be the main benefitting port).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When this commit was originally introduced, Windows/ARM64 support was a
fantasy.
In the meantime it is reality and we need to do a better job of setting
`MSYSTEM` and the `PATH`: We want to support Windows/ARM64 properly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's make the `.dll` copying a bit more robust. At least in my hands,
the check sometimes failed to detect whether there are any `.dll` files
to be copied.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The original test case obviously only worked in the x86_64 flavor of Git
for Windows (and since I rarely test on i686, this was not caught).
This completely breaks on Windows/ARM64:
+++ GIT_DIR=/dev/null
+++ git diff --no-index --ignore-cr-at-eol -- expect actual
diff --git a/expect b/actual
index e0dc09e..2301bbf 100644
--- a/expect
+++ b/actual
@@ -1,3 +1,3 @@
-MSYSTEM=CLANGARM64
+MSYSTEM=MINGW64
mingw64
usr
error: last command exited with $?=1
not ok 221 - MSYSTEM/PATH is adjusted if necessary
To fix that, let's rely on `MINGW_PREFIX` (falling back to constructing
it from `MSYSTEM`, defaulting to `MINGW64` if _that_ is unset, too).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I noticed that the CI builds of `shears/main` were failing, as well as
the PR builds of #5586. The reasons are outside of Git for Windows, but
the fixes need to be inside anyway.
The image pointed to by the fedora:latest tag has moved from fedora 41
to 42. The fedora 41 container images have awk installed while the
fedora 42 images do not. That change is most likely just part of
reducing the size of the base container images.
In both AlmaLinux and Fedora (as well as other RHEL
derivatives/relatives), awk is provided by the gawk package.
On Fedora, `dnf install awk` would work, but for unintended reasons! It
uses the package filelist data to determine that /usr/bin/awk is
provided by gawk and installs gawk as a result.
On AlmaLinux (8 & 9, by my quick testing), that is not the case and
you'd need to use `dnf install gawk` or `dnf install '*bin/awk'` to get
it installed. Having said that, awk _is_ included in the current
AlmaLinux 8 and 9 images, so it isn't strictly needed. But it's
probably better to be explicit that we need it installed, as a defense
against some future change to the AlmaLinux container removing awk.
Using the package name "gawk" is the right thing to do.
Note that even '*bin/awk' would have worked, but it is less specific.
And who knows, maybe in the far future a BSD variant of awk is offered,
too, and would then cause ambiguities. Best to avoid that.
Suggested-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is Exhibit B to make the case that maintenance is always required,
a software is never "done".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is Exhibit A to make the case that maintenance is always required,
a software is never "done".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `sparse` job still uses the `ubuntu-20.04` runner pool, but that
pool is about to go away, so let's stop using it.
There is no `sparse-22.04` artifact provided by the "Build sparse for
Ubuntu" Azure Pipeline, but that is not necessary anyway because Ubuntu
22.04 has the `sparse` package: https://packages.ubuntu.com/jammy/sparse
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With at least glibc 2.39, glibc provides a function declaration that
matches with this POSIX interface:
int regexec(const regex_t *restrict preg, const char *restrict string,
size_t nmatch, regmatch_t pmatch[restrict], int eflags);
such prototype requires variable-length-array for `pmatch'.
Thus, sparse reports this error:
> ../add-patch.c: note: in included file (through ../git-compat-util.h):
> /usr/include/regex.h:682:41: error: undefined identifier '__nmatch'
> /usr/include/regex.h:682:41: error: bad constant expression type
> /usr/include/regex.h:682:41: error: Variable length array is used.
Note: `__nmatch' is POSIX's nmatch.
The glibc's intention is informing their users to provides a large
enough buffer to hold `__nmatch' results and provides diagnosis if
necessary. It's merely a glibc' implementation detail.
Hide that usage from sparse by using standard C11's macro:
__STDC_NO_VLA__
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing c8b6c1db91 (mingw: support long paths, 2015-07-28) on
top of 391bceae43 (compat/mingw: support POSIX semantics for atomic
renames, 2024-10-27) a newly introduced MAX_PATH buffer was not
increased to MAX_LONG_PATH.
This fixes https://github.com/git-for-windows/git/issues/5476
Git on Windows 2022 fails to write config files on ReFS with the error
message "Function not implemented". The reason is that
`ERROR_NOT_SUPPORTED` is reported (not `ERROR_INVALID_PARAMETER`, as
expected). Let's handle both errors the same: by falling back to the
best-effort option, namely to rename without POSIX semantics.
This fixes https://github.com/git-for-windows/git/issues/5427
ReFS is an alternative filesystem to NTFS. On Windows 2022, it seems not
to support the rename operation using POSIX semantics that Git uses on
Windows as of 391bceae43 (compat/mingw: support POSIX semantics for
atomic renames, 2024-10-27).
However, Windows 2022 reports `ERROR_NOT_SUPPORTED` in this instance.
This is in contrast to `ERROR_INVALID_PARAMETER` (as previous Windows
versions would report that do not support POSIX semantics in renames at
all).
Let's handle both errors the same: by falling back to the best-effort
option, namely to rename without POSIX semantics.
This fixes https://github.com/git-for-windows/git/issues/5427
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We want to compile mimalloc's source code as part of Git, rather than
requiring the code to be built as an external library: mimalloc uses a
CMake-based build, which is not necessarily easy to integrate into the
flavors of Git for Windows (which will be the main benefitting port).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In preparation for upgrading to a newer mimalloc version; This patch
will not be needed anymore, as it has been implemented in a slightly
different form in upstream mimalloc: 3e1d800e (potential fix for windows
static linking with thread creation in dll's, 2022-11-07).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Instead of trying to "fix" whitespace issues in mimalloc's source,
thereby making it unnecessarily complicated to keep the vendored-in
mimalloc sources in sync, let's just prevent Git from trying to enforce
its coding style rules on said vendored-in source files.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Now that Git is a bit stricter when compiling its own source, we need to
exempt mimalloc a bit more.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Originally introduced as `core.useBuiltinFSMonitor` in Git for Windows
and developed, improved and stabilized there, the built-in FSMonitor
only made it into upstream Git (after unnecessarily long hemming and
hawing and throwing overly perfectionist style review sticks into the
spokes) as `core.fsmonitor = true`.
In Git for Windows, with this topic branch, we re-introduce the
now-obsolete config setting, with warnings suggesting to existing users
how to switch to the new config setting, with the intention to
ultimately drop the patch at some stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch re-adds the deprecated --stdin/-z options to `git
reset`. Those patches were overridden by a different set of options in
the upstream Git project before we could propose `--stdin`.
We offered this in MinGit to applications that wanted a safer way to
pass lots of pathspecs to Git, and these applications will need to be
adjusted.
Instead of `--stdin`, `--pathspec-from-file=-` should be used, and
instead of `-z`, `--pathspec-file-nul`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A fix for calling `vim` in Windows Terminal caused a regression and was
reverted. We partially un-revert this, to get the fix again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch introduces support to set special NTFS attributes that are
interpreted by the Windows Subsystem for Linux as file mode bits, UID
and GID.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With this patch, Git for Windows works as intended on mounted APFS
volumes (where renaming read-only files would fail).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
