Rebase shears/next: 1 conflict(s) (0 skipped, 1 resolved) (#43123789593) - #607

Add FileVersion, which is a required field
As not all required fields were present, none were being included
Fixes git-for-windows#4090

Signed-off-by: Kiel Hurley <[email protected]>

In f9b7573 (repository: free fields before overwriting them,
2017-09-05), Git was taught to release memory before overwriting it, but
357a03e (repository.c: move env-related setup code back to
environment.c, 2018-03-03) changed the code so that it would not
_always_ be overwritten.

As a consequence, the `commondir` attribute would point to
already-free()d memory.

This seems not to cause problems in core Git, but there are add-on
patches in Git for Windows where the `commondir` attribute is
subsequently used and causing invalid memory accesses e.g. in setups
containing old-style submodules (i.e. the ones with a `.git` directory
within theirs worktrees) that have `commondir` configured.

This fixes git-for-windows#4083.

Signed-off-by: Andrey Zabavnikov <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

In 436a422 (max_tree_depth: lower it for clangarm64 on Windows,
2025-04-23), I provided a work-around for a nasty issue with clangarm
builds, where the stack is exhausted before the maximal tree depth is
reached, and the resulting error cannot easily be handled by Git
(because it would require Windows-specific handling).

Turns out that this is not at all limited to ARM64. In my tests with
CLANG64 in MSYS2 on the GitHub Actions runners, the test t6700.4 failed
in the exact same way. What's worse: The limit needs to be quite a bit
lower for x86_64 than for aarch64. In aforementioned tests, the breaking
point was 1232: With 1231 it still worked as expected, with 1232 it
would fail with the `STATUS_STACK_OVERFLOW` incorrectly mapped to exit
code 127. For comparison, in my tests on GitHub Actions' Windows/ARM64
runners, the breaking point was 1439 instead.

Therefore the condition needs to be adapted once more, to accommodate
(with some safety margin) both aarch64 and x86_64 in clang-based builds
on Windows, to let that test pass.

Signed-off-by: Johannes Schindelin <[email protected]>

…ctory

Internally, Git expects the environment variable `HOME` to be set, and
to point to the current user's home directory.

This environment variable is not set by default on Windows, and
therefore Git tries its best to construct one if it finds `HOME` unset.

There are actually two different approaches Git tries: first, it looks
at `HOMEDRIVE`/`HOMEPATH` because this is widely used in corporate
environments with roaming profiles, and a user generally wants their
global Git settings to be in a roaming profile.

Only when `HOMEDRIVE`/`HOMEPATH` is either unset or does not point to a
valid location, Git will fall back to using `USERPROFILE` instead.

However, starting with Windows Vista, for secondary logons and services,
the environment variables `HOMEDRIVE`/`HOMEPATH` point to Windows'
system directory (usually `C:\Windows\system32`).

That is undesirable, and that location is usually write-protected anyway.

So let's verify that the `HOMEDRIVE`/`HOMEPATH` combo does not point to
Windows' system directory before using it, falling back to `USERPROFILE`
if it does.

This fixes git-for-windows#2709

Initial-Path-by: Ivan Pozdeev <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

headless-git is a git executable without opening a console window. It is
useful when other GUI executables want to call git. We should install it
together with git on Windows.

Signed-off-by: Yuyi Wang <[email protected]>

winuser.h contains the definition of RT_MANIFEST that our LLVM based
toolchain needs to understand that we want to embed
compat/win32/git.manifest as an application manifest. It currently just
embeds it as additional data that Windows doesn't understand.

This also helps our GCC based toolchain understand that we only want one
copy embedded. It currently embeds one working assembly manifest and one
nearly identical, but useless copy as additional data.

This also teaches our Visual Studio based buildsystems to pick up the
manifest file from git.rc. This means we don't have to explicitly specify
it in contrib/buildsystems/Generators/Vcxproj.pm anymore. Slightly
counter-intuitively this also means we have to explicitly tell Cmake
not to embed a default manifest.

This fixes git-for-windows#4707

Signed-off-by: Matthias Aßhauer <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

This will help with Git for Windows' maintenance going forward: It
allows Git for Windows to switch its primary libcurl to a variant
without the OpenSSL backend, while still loading an alternate when
setting `http.sslBackend = openssl`.

This is necessary to avoid maintenance headaches with upgrading OpenSSL:
its major version name is encoded in the shared library's file name and
hence major version updates (temporarily) break libraries that are
linked against the OpenSSL library.

Signed-off-by: Johannes Schindelin <[email protected]>

In Git for Windows v2.39.0, we fixed a regression where `git.exe` would
no longer work in Windows Nano Server (frequently used in Docker
containers).

This GitHub workflow can be used to verify manually that the Git/Scalar
executables work in Nano Server.

Signed-off-by: Johannes Schindelin <[email protected]>

When running Git for Windows on a remote APFS filesystem, it would
appear that the `mingw_open_append()`/`write()` combination would fail
almost exactly like on some CIFS-mounted shares as had been reported in
git-for-windows#2753, albeit with a
different `errno` value.

Let's handle that `errno` value just the same, by suggesting to set
`windows.appendAtomically=false`.

Signed-off-by: David Lomas <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

Windows 10 version 1511 (also known as Anniversary Update), according to
https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
introduced native support for ANSI sequence processing. This allows
using colors from the entire 24-bit color range.

All we need to do is test whether the console's "virtual processing
support" can be enabled. If it can, we do not even need to start the
`console_thread` to handle ANSI sequences.

Or, almost all we need to do: When `console_thread()` does its work, it
uses the Unicode-aware `write_console()` function to write to the Win32
Console, which supports Git for Windows' implicit convention that all
text that is written is encoded in UTF-8. The same is not necessarily
true if native ANSI sequence processing is used, as the output is then
subject to the current code page. Let's ensure that the code page is set
to `CP_UTF8` as long as Git writes to it.

Signed-off-by: Johannes Schindelin <[email protected]>

By default, the buffer type of Windows' `stdout` is unbuffered (_IONBF),
and there is no need to manually fflush `stdout`.

But some programs, such as the Windows Filtering Platform driver
provided by the security software, may change the buffer type of
`stdout` to full buffering. This nees `fflush(stdout)` to be called
manually, otherwise there will be no output to `stdout`.

Signed-off-by: MinarKotonoha <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

A long time ago, we decided to run tests in Git for Windows' SDK with
the default `winsymlinks` mode: copying instead of linking. This is
still the default mode of MSYS2 to this day.

However, this is not how most users run Git for Windows: As the majority
of Git for Windows' users seem to be on Windows 10 and newer, likely
having enabled Developer Mode (which allows creating symbolic links
without administrator privileges), they will run with symlink support
enabled.

This is the reason why it is crucial to get the fixes for CVE-2024-? to
the users, and also why it is crucial to ensure that the test suite
exercises the related test cases. This commit ensures the latter.

Signed-off-by: Johannes Schindelin <[email protected]>

In order to be a better Windows citizenship, Git should
save its configuration files on AppData folder. This can
enables git configuration files be replicated between machines
using the same Microsoft account logon which would reduce the
friction of setting up Git on new systems. Therefore, if
%APPDATA%\Git\config exists, we use it; otherwise
$HOME/.config/git/config is used.

Signed-off-by: Ariel Lourenco <[email protected]>

The sparse tree walk algorithm was created in d5d2e93 (revision:
implement sparse algorithm, 2019-01-16) and involves using the
mark_trees_uninteresting_sparse() method. This method takes a repository
and an oidset of tree IDs, some of which have the UNINTERESTING flag and
some of which do not.

Create a method that has an equivalent set of preconditions but uses a
"dense" walk (recursively visits all reachable trees, as long as they
have not previously been marked UNINTERESTING). This is an important
difference from mark_tree_uninteresting(), which short-circuits if the
given tree has the UNINTERESTING flag.

A use of this method will be added in a later change, with a condition
set whether the sparse or dense approach should be used.

Signed-off-by: Derrick Stolee <[email protected]>

While this command is definitely something we _want_, chances are that
upstreaming this will require substantial changes.

We still want to be able to experiment with this before that, to focus
on what we need out of this command: To assist with diagnosing issues
with large repositories, as well as to help monitoring the growth and
the associated painpoints of such repositories.

To that end, we are about to integrate this command into
`microsoft/git`, to get the tool into the hands of users who need it
most, with the idea to iterate in close collaboration between these
users and the developers familar with Git's internals.

However, we will definitely want to avoid letting anybody have the
impression that this command, its exact inner workings, as well as its
output format, are anywhere close to stable. To make that fact utterly
clear (and thereby protect the freedom to iterate and innovate freely
before upstreaming the command), let's mark its output as experimental
in all-caps, as the first thing we do.

Signed-off-by: Johannes Schindelin <[email protected]>

`git survey` was an experimental scale-measurement tool whose
distinctive features (ref-kind filters, top-N path tables) are now
all available in `git repo structure`. With the path-level reporting
in place (commits "repo: filter the structure scope via
--ref-filter=<pattern>" and "repo: report top-N paths by count, disk,
and inflated size in structure"), there is no functionality `git
survey` provides that `git repo structure` cannot.

Replace the 764-line `git survey` implementation with a roughly
hundred-line shim that:

  * Accepts the existing `git survey` command line so callers in
    scripts continue to parse without changes.
  * Emits a deprecation warning naming the replacement command, so
    interactive users learn about the migration target.
  * Translates the survey-specific knobs into the equivalent
    `git repo structure` invocation and re-execs the canonical
    command via `execv_git_cmd()`. Per-kind ref selectors fan out
    into the corresponding `refs/heads/*`, `refs/tags/*`, etc.
    `--ref-filter` patterns; `--top=<N>` is forwarded directly;
    `--all-refs` becomes the absence of any `--ref-filter`.

Two survey options have no `git repo structure` counterpart:
`--verbose` controlled per-step trace output the new command does
not emit, and `--detached` selected the detached HEAD which
`git repo structure` does not enumerate separately. Both are
silently accepted and produce a single warning each, so old
invocations keep working while the absence of these knobs in `git
repo structure` is made visible.

Rewrite t8100 to assert the shim's contract: the deprecation
warning is printed, the output is byte-identical to a corresponding
`git repo structure` invocation, and the per-kind selector
translation produces the right `--ref-filter` pattern. The
preceding survey-specific output assertions (the multi-column
plaintext tables) no longer apply, since `git repo structure`'s
output format is now the canonical one and is covered by t1901.

The `survey.*` configuration keys (`survey.top`, `survey.progress`,
`survey.verbose`) are no longer honored by the shim. They were
mirrored by the preceding `repo.structure.top` work for the most
useful knob; users with `survey.top` set in config should migrate
to `repo.structure.top`. This is a backward-incompatible removal
documented by the deprecation notice in `git-survey.adoc`.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

In 245670c (credential-cache: check for windows specific errors, 2021-09-14)
we concluded that on Windows we would always encounter ENETDOWN where we
would expect ECONNREFUSED on POSIX systems, when connecting to unix sockets.
As reported in [1], we do encounter ECONNREFUSED on Windows if the
socket file doesn't exist, but the containing directory does and ENETDOWN if
neither exists. We should handle this case like we do on non-windows systems.

[1] git-for-windows#4762 (comment)

This fixes git-for-windows#5314

Helped-by: M Hickford <[email protected]>
Signed-off-by: Matthias Aßhauer <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

The reftable library goes out of its way to use its own set of allocator
functions that can be configured using `reftable_set_alloc()`. However,
Git does not configure this.

That is not typically a problem, except when Git uses a custom allocator
via some definitions in `git-compat-util.h`, as is the case in Git for
Windows (which switched away from the long-unmaintained nedmalloc to
mimalloc).

Then, it is quite possible that Git assigns a `strbuf` (allocated via
the custom allocator) to, say, the `refname` field of a
`reftable_log_record` in `write_transaction_table()`, and later on asks
the reftable library function `reftable_log_record_release()` to release
it, but that function was compiled without using `git-compat-util.h` and
hence calls regular `free()` (i.e. _not_ the custom allocator's own
function).

This has been a problem for a long time and it was a matter of some sort
of "luck" that 1) reftables are not commonly used on Windows, and 2)
mimalloc can often ignore gracefully when it is asked to release memory
that it has not allocated.

However, a recent update to `seen` brought this problem to the
forefront, letting t1460 fail in Git for Windows, with symptoms much in
the same way as the problem I had to address in d02c37c
(t-reftable-basics: allow for `malloc` to be `#define`d, 2025-01-08)
where exit code 127 was also produced in lieu of
`STATUS_HEAP_CORRUPTION` (C0000374) because exit codes are only 7 bits
wide.

It was not possible to figure out what change in particular caused these
new failures within a reasonable time frame, as there are too many
changes in `seen` that conflict with Git for Windows' patches, I had to
stop the investigation after spending four hours on it fruitlessly.

To verify that this patch fixes the issue, I avoided using mimalloc and
temporarily patched in a "custom allocator" that would more reliably
point out problems, like this:

  diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
  index 68f3829..9421d630b9f5 100644
  --- a/refs/reftable-backend.c
  +++ b/refs/reftable-backend.c
  @@ -353,6 +353,69 @@ static int reftable_be_fsync(int fd)
   	return fsync_component(FSYNC_COMPONENT_REFERENCE, fd);
   }

  +#define DEBUG_REFTABLE_ALLOC
  +#ifdef DEBUG_REFTABLE_ALLOC
  +#include "khash.h"
  +
  +static inline khint_t __ac_X31_hash_ptr(void *ptr)
  +{
  +	union {
  +		void *ptr;
  +		char s[sizeof(void *)];
  +	} u;
  +	size_t i;
  +	khint_t h;
  +
  +	u.ptr = ptr;
  +	h = (khint_t)*u.s;
  +	for (i = 0; i < sizeof(void *); i++)
  +		h = (h << 5) - h + (khint_t)u.s[i];
  +	return h;
  +}
  +
  +#define kh_ptr_hash_func(key) __ac_X31_hash_ptr(key)
  +#define kh_ptr_hash_equal(a, b) ((a) == (b))
  +
  +KHASH_INIT(ptr, void *, int, 0, kh_ptr_hash_func, kh_ptr_hash_equal)
  +
  +static kh_ptr_t *my_malloced;
  +
  +static void *my_malloc(size_t sz)
  +{
  +	int dummy;
  +	void *ptr = malloc(sz);
  +	if (ptr)
  +		kh_put_ptr(my_malloced, ptr, &dummy);
  +	return ptr;
  +}
  +
  +static void *my_realloc(void *ptr, size_t sz)
  +{
  +	int dummy;
  +	if (ptr) {
  +		khiter_t pos = kh_get_ptr(my_malloced, ptr);
  +		if (pos >= kh_end(my_malloced))
  +			die("Was not my_malloc()ed: %p", ptr);
  +		kh_del_ptr(my_malloced, pos);
  +	}
  +	ptr = realloc(ptr, sz);
  +	if (ptr)
  +		kh_put_ptr(my_malloced, ptr, &dummy);
  +	return ptr;
  +}
  +
  +static void my_free(void *ptr)
  +{
  +	if (ptr) {
  +		khiter_t pos = kh_get_ptr(my_malloced, ptr);
  +		if (pos >= kh_end(my_malloced))
  +			die("Was not my_malloc()ed: %p", ptr);
  +		kh_del_ptr(my_malloced, pos);
  +	}
  +	free(ptr);
  +}
  +#endif
  +
   static struct ref_store *reftable_be_init(struct repository *repo,
   					  const char *gitdir,
   					  unsigned int store_flags)
  @@ -362,6 +425,11 @@ static struct ref_store *reftable_be_init(struct repository *repo,
   	int is_worktree;
   	mode_t mask;

  +#ifdef DEBUG_REFTABLE_ALLOC
  +	my_malloced = kh_init_ptr();
  +	reftable_set_alloc(my_malloc, my_realloc, my_free);
  +#endif
  +
   	mask = umask(0);
   	umask(mask);

I briefly considered contributing this "custom allocator" patch, too,
but it is unwieldy (for example, it would not work at all when compiling
with mimalloc support) and it would only waste space (or even time, if a
compile flag was introduced and exercised as part of the CI builds).
Given that it is highly unlikely that Git will lose the new
`reftable_set_alloc()` call by mistake, I rejected that idea as simply
too wasteful.

Signed-off-by: Johannes Schindelin <[email protected]>

Every once in a while, whitespace errors are introduced in Git for
Windows' rebases to newer Git versions, simply by virtue of integrating
upstream commits that do not follow upstream Git's own whitespace rule.
In Git v2.50.0-rc0, for example, 03f2915 (xdiff: disable
cleanup_records heuristic with --minimal, 2025-04-29) introduced a
trailing space.

Arguably, non-actionable alerts are worse than no alerts at all, so
let's suppress those alerts that we cannot do anything about, anyway.

Signed-off-by: Johannes Schindelin <[email protected]>

The 2.53.0.rc0.windows release candidate had a regression where
writing to stderr from a pre-push hook would error out.

The regression was fixed in 2.53.0.rc1.windows and the test here ensures
that this stays fixed.

Signed-off-by: Thomas Braun <[email protected]>

The previous commits disabled NTLM authentication by default due to its
cryptographic weaknesses. Users can re-enable it via the config setting
http.<url>.allowNTLMAuth, but this requires manual intervention.

Credential helpers may have knowledge about which servers are trusted
for NTLM authentication (e.g., known on-prem Azure DevOps instances).
To allow them to signal this trust, introduce a simple negotiation:
when NTLM is suppressed and the server offered it, Git advertises
ntlm=suppressed to the credential helper. The helper can respond with
ntlm=allow to re-enable NTLM for this request.

This happens precisely at the point where we would otherwise warn the
user about NTLM being suppressed, ensuring the capability is only
advertised when relevant.

Helped-by: Matthew John Cheetham <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

It was already decided in ef22148 (clean: do not traverse mount points,
2018-12-07) that we shouldn't traverse NTFS junctions/bind mounts when
using `git clean`, partly because they're sometimes used in worktrees.
But the same check wasn't applied to `remove_dir_recurse()` in `dir.c`,
which `git worktree remove` uses. So removing a worktree suffers the
same problem we had previously with `git clean`.

Let's add the same guard from ef22148.

Signed-off-by: Maks Kuznia <[email protected]>

While the currently used way to detect the number of CPU cores on
Windows is nice and straight-forward, GetSystemInfo() only gives us
access to the number of processors within the current group. [1]

While that is usually fine for systems with a single physical CPU,
separate physical sockets are typically separate groups.

Switch to using GetLogicalProcessorInformationEx() to handle multi-socket
systems better.

[1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info#members

This fixes git-for-windows#4766

Co-Authored-by: Herman Semenov <[email protected]>
Signed-off-by: Matthias Aßhauer <[email protected]>

Add tests exercising the interaction between http.emptyAuth and
servers that advertise Negotiate (SPNEGO) authentication.

Verify that auto mode gives Negotiate a chance via empty auth
(resulting in two 401 responses before falling through to
credential_fill with Basic credentials), and that false mode
strips Negotiate immediately (only one 401 response).

Signed-off-by: Matthew John Cheetham <[email protected]>

Continue the size_t evacuation around large object handling: with
deflate_it() and the locals around it widened, the
cast_size_t_to_ulong() shim the prior delta_delta() widening had to
leave behind in emit_binary_diff_body() goes away. deflate_it() is
file-static; the only callers are the two in emit_binary_diff_body()
already touched here.

emit_diff_symbol() formats the resulting sizes via uintmax_t / %"PRIuMAX",
so the diff output is not affected; only the per-process upper bound
on a binary patch chunk that this function can address grows beyond
4 GiB on Windows.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

Prep for the upcoming read_blob_data_from_index() widening, whose
callers in convert.c feed the size they receive straight into these
two helpers. Both are file-static, so the change is contained.

Also fixes a small pre-existing narrowing on the get_wt_convert_stats_ascii()
path, where strbuf.len (size_t) was passed to a unsigned long
parameter.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

Continue the size_t evacuation. read_blob_data_from_index() reads
the blob through the size_t odb_read_object() API but writes the
size back through an unsigned long out-parameter, silently
truncating anything past 4 GiB on Windows. Widen the out-parameter,
drop the cast_size_t_to_ulong() shim, and move the matching locals
in the two convert.c callers and the one in attr.c. Their
downstream consumers (gather_convert_stats() widened in the prior
commit and read_attr_from_buf() already size_t) take the new type
directly.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

Prep for the widenings of its callers, where size-receiving locals
will become size_t (combine-diff's result_size in the immediately
following commit, struct diff_filespec.size in a later topic). Body
caps the parameter at 8000 anyway, so the type change is mechanical.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

Smallest piece of the tree topic. link_len is only used as
strbuf_splice()'s size_t length and as an array index; widening it
outright removes the cast_size_t_to_ulong() shim and the bridge
local that fed it. odb_read_object() now writes straight into
link_len.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <[email protected]>

On Windows, git repositories may have extra files which need cleaned
(e.g., a build directory) that may be arbitrarily deep. Suggest using
`core.longPaths` if such situations are encountered.

Fixes: git-for-windows#2715
Signed-off-by: Ben Boeckel <[email protected]>

These are Git for Windows' Git GUI and gitk patches. We will have to
decide at some point what to do about them, but that's a little lower
priority (as Git GUI seems to be unmaintained for the time being, and
the gitk maintainer keeps a very low profile on the Git mailing list,
too).

Signed-off-by: Johannes Schindelin <[email protected]>

Rather than using private IFTTT Applets that send mails to this
maintainer whenever a new version of a Git for Windows component was
released, let's use the power of GitHub workflows to make this process
publicly visible.

This workflow monitors the Atom/RSS feeds, and opens a ticket whenever a
new version was released.

Note: Bash sometimes releases multiple patched versions within a few
minutes of each other (i.e. 5.1p1 through 5.1p4, 5.0p15 and 5.0p16). The
MSYS2 runtime also has a similar system. We can address those patches as
a group, so we shouldn't get multiple issues about them.

Note further: We're not acting on newlib releases, OpenSSL alphas, Perl
release candidates or non-stable Perl releases. There's no need to open
issues about them.

Co-authored-by: Matthias Aßhauer <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.

Helped-by: Sven Strickroth <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

On Windows, the current working directory is pretty much guaranteed to
contain a colon. If we feed that path to CVS, it mistakes it for a
separator between host and port, though.

This has not been a problem so far because Git for Windows uses MSYS2's
Bash using a POSIX emulation layer that also pretends that the current
directory is a Unix path (at least as long as we're in a shell script).

However, that is rather limiting, as Git for Windows also explores other
ports of other Unix shells. One of those is BusyBox-w32's ash, which is
a native port (i.e. *not* using any POSIX emulation layer, and certainly
not emulating Unix paths).

So let's just detect if there is a colon in $PWD and punt in that case.

Signed-off-by: Johannes Schindelin <[email protected]>

…ITOR"

In e3f7e01 (Revert "editor: save and reset terminal after calling
EDITOR", 2021-11-22), we reverted the commit wholesale where the
terminal state would be saved and restored before/after calling an
editor.

The reverted commit was intended to fix a problem with Windows Terminal
where simply calling `vi` would cause problems afterwards.

To fix the problem addressed by the revert, but _still_ keep the problem
with Windows Terminal fixed, let's revert the revert, with a twist: we
restrict the save/restore _specifically_ to the case where `vi` (or
`vim`) is called, and do not do the same for any other editor.

This should still catch the majority of the cases, and will bridge the
time until the original patch is re-done in a way that addresses all
concerns.

Signed-off-by: Johannes Schindelin <[email protected]>

The `--stdin` option was a well-established paradigm in other commands,
therefore we implemented it in `git reset` for use by Visual Studio.

Unfortunately, upstream Git decided that it is time to introduce
`--pathspec-from-file` instead.

To keep backwards-compatibility for some grace period, we therefore
reinstate the `--stdin` option on top of the `--pathspec-from-file`
option, but mark it firmly as deprecated.

Helped-by: Victoria Dye <[email protected]>
Helped-by: Matthew John Cheetham <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

Reintroduce the 'core.useBuiltinFSMonitor' config setting (originally added
in 0a756b2 (fsmonitor: config settings are repository-specific,
2021-03-05)) after its removal from the upstream version of FSMonitor.

Upstream, the 'core.useBuiltinFSMonitor' setting was rendered obsolete by
"overloading" the 'core.fsmonitor' setting to take a boolean value. However,
several applications (e.g., 'scalar') utilize the original config setting,
so it should be preserved for a deprecation period before complete removal:

* if 'core.fsmonitor' is a boolean, the user is correctly using the new
  config syntax; do not use 'core.useBuiltinFSMonitor'.
* if 'core.fsmonitor' is unspecified, use 'core.useBuiltinFSMonitor'.
* if 'core.fsmonitor' is a path, override and use the builtin FSMonitor if
  'core.useBuiltinFSMonitor' is 'true'; otherwise, use the FSMonitor hook
  indicated by the path.

Additionally, for this deprecation period, advise users to switch to using
'core.fsmonitor' to specify their use of the builtin FSMonitor.

Signed-off-by: Victoria Dye <[email protected]>

See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot#enabling-dependabot-version-updates-for-actions for details.

Signed-off-by: Johannes Schindelin <[email protected]>

Upstream Git does not test their tags with the expensive set of tests,
so a couple of them seem quite broken for now, even so much as hanging
indefinitely.

It is outside of the responsibility of the Git for Windows project to
fix upstream's own tests for platforms other than Windows, so let's not
exercise them.

Signed-off-by: Johannes Schindelin <[email protected]>

Signed-off-by: Johannes Schindelin <[email protected]>

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

…updates

Start monitoring updates of Git for Windows' component in the open

The special-casing of `NUL` in `mingw_access()` was added in
9160068 (msvc: avoid calling `access("NUL", flags)`, 2021-04-16)
because the Universal C Runtime's ("UCRT") `_waccess()` rejects `NUL` as
an invalid argument.

With the switch of GIt for Windows from the MSVCRT-based MINGW64 build
to the UCRT-based UCRT64 build in 2.56.0, any spelling other than
lowercase `nul` now reaches `_waccess()` and fails. Windows device names
are case-insensitive, and `NUL` is the canonical spelling, but even
`Nul` is allowed, so a case-insensitive comparison is needed.

Note that we cannot use `fspathcmp()` here, as we would usually do: This
function is in the code path when reading the config, and
`core.ignoreCase` would therefore not be set correctly yet e.g. when
running under `GIT_CONFIG_GLOBAL=NUL`.

This fixes git-for-windows#6449

Signed-off-by: Johannes Schindelin <[email protected]>

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <[email protected]>

…r-windows#6450)

Currently, when running `GIT_CONFIG_GLOBAL=NUL git config --list`, it
fails with:

```
fatal: unable to access 'NUL': Invalid argument
```

The underlying reason is the different behavior of the C runtime used by
MINGW64 vs UCRT64. Let's accommodate for that.

This fixes git-for-windows#6449

This bumps `actions/setup-python from version 6 to 7. The main change is
that this is now an ECMAScript Module, which bumps the minimum
requirements for GitHub Enterprise Server setups enough to warrant a
full major version bump.

Release notes: https://github.com/actions/setup-python/releases
Commits: actions/setup-python@v6...v7

Originally-authored-by: dependabot[bot] <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>

I ran into these new failures (caused by an upgrade to libcurl v8.23.0
in CI builds) in Microsoft Git and fixed them via
microsoft#1007; This is a companion to
fast-track the same fix into Git for Windows.

…erver

Nano Server needs runtime DLLs from the SDK used to build Git, but the
current x64 environment no longer contains `/mingw64/bin`. Honor the
setup action's `MSYSTEM` selection while keeping the container-side
directory independent of the toolchain name.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <[email protected]>

…opment

The PowerShell example still assumes `/mingw64`, which is absent from
the current x64 SDK. Keep its environment and search path consistent
with UCRT64 while preserving the non-login `bash` invocation and access
to `/usr/bin`.

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <[email protected]>

The deprecation note still promises behavior intentionally removed by
the shim. Explain the migration to `git repo structure` so users can
choose their ref scope and output without relying on ignored configuration
or unsupported options.

Assisted-by: GPT-6 Astra and GPT-6.1 Sol
Signed-off-by: Johannes Schindelin <[email protected]>

The test reporter fails with "Permission denied" when appending
`FAILED_TEST_ARTIFACTS` to `GITHUB_ENV` in linux-TEST-vars, linux32 and
debian-12:
https://github.com/microsoft/git/actions/runs/35114876023

Each Actions step receives a distinct environment file, so the earlier
build/test permission adjustment does not cover the reporter. Give this
step the access it needs to record failure artifacts while retaining
rootless execution and unchanged reporting logic.

I overlooked this in the original 0458e8b (ci(dockerized): do show
the result of failing tests again, 2025-11-17).

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <[email protected]>

The pretend SDK layout should reflect the current x64 UCRT64 defaults
when neither `MINGW_PREFIX` nor `MSYSTEM` is specified. Explicit
selections remain honored; only the fixture's fallback changes.

I forgot this part before upstreaming caa5d9e (mingw: allow
`git.exe` to be used instead of the "Git wrapper", 2026-09-10).

Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <[email protected]>

We haven't been on Gitter in quite a while. Let's remove the misleading
badge.

Signed-off-by: Johannes Schindelin <[email protected]>

Apparently the badge URL has changed at some stage. I must have missed
this, and I do not regularly look at that badge. But when I did, I saw
that it says "failing" even though the CI runs were successful (I
checked, after re-enabling Actions in git-for-windows/git that GitHub so
helpfully "disabled [...] on this forked repository because of its
Actions usage").

So I followed the guidance (or more correctly: **tried* to follow) at
https://docs.github.com/en/actions/how-tos/monitor-workflows/add-a-status-badge,
which kind of worked after not finding the promised `⋯` menu but
realizing that there was a section on how to manually construct the URL.

Signed-off-by: Johannes Schindelin <[email protected]>

…r-windows#6345)

A symlink on Windows has to be created as either a file symlink or a
directory symlink. If the target doesn't exist yet we can't tell which
one it should be, so Git remembers it as a "phantom" symlink and tries
again later. The catch is that all of the phantoms live in a single
list, and that whole list is walked on every `mkdir()`. The cost ends up
being (pending symlinks × directories created).

On Discord's monorepo (343 symlinks, about 37,000 directories) that works
out to 330 seconds for a checkout, with 12.7 million calls to
`process_phantom_symlink()`.

Fix this via the following:
- Phantom symlinks are indexed by their target path in a `cbtree`, so
creating a directory only retries the symlinks it could actually affect.
- Directory prefixes that were already canonicalized are cached, which
saves re-resolving the same parents over and over.
- Two path resolution fixes that the above depends on: a dangling
symlink is no longer mistaken for a missing path, and junctions are
resolved before missing path components.
- Tests for symlinks that point through other symlinks (t2040), through
a junction (t2041), and a perf test (p2041).

Originally implemented as a trie, this topic avoids a separate implementation
of a trie by reusing the already-existing cbtree implementation. On the same
fixture the checkout takes about 55 seconds both with the original trie and
the current cbtree-based version.