Skip to content

Rebase shears/main: 2 conflict(s) (0 skipped, 2 resolved) (#40444356654) - #561

Open
gitforwindowshelper[bot] wants to merge 334 commits into
base/shears/main-40444356654from
shears/main-40444356654
Open

gitforwindowshelper[bot] wants to merge 334 commits into
base/shears/main-40444356654from
shears/main-40444356654

Conversation

@gitforwindowshelper

Copy link
Copy Markdown

Workflow run

Rebase Summary: main

From: c7b63be733 (ci: pin linux32 to ubuntu-24.04 to restore networking, 2026-10-25) (0af8f0e529..c7b63be733)

Resolved: b8cc892 (fast-import: drop the six size casts in the object-read paths, 2026-06-05)

preserved upstream in-progress object lookup while converting object sizes to size_t

Range-diff
  • 1: b8cc892 ! 1: e8bed2b fast-import: drop the six size casts in the object-read paths

    @@ builtin/fast-import.c: static void parse_from_existing(struct branch *b)
      		oidclr(&b->branch_tree.versions[1].oid, the_repository->hash_algo);
      	} else {
     -		unsigned long size;
    --		size_t size_st = 0;
     +		size_t size;
      		char *buf;
    + 		struct object_entry *e = find_object(&b->oid);
      
    - 		buf = odb_read_object_peeled(the_repository->objects, &b->oid,
    --					     OBJ_COMMIT, &size_st, &b->oid);
    --		size = cast_size_t_to_ulong(size_st);
    -+					     OBJ_COMMIT, &size, &b->oid);
    +@@ builtin/fast-import.c: static void parse_from_existing(struct branch *b)
    + 		if (e && e->type == OBJ_COMMIT && e->pack_id != MAX_PACK_ID) {
    + 			buf = gfi_unpack_entry(e, &size);
    + 		} else {
    +-			size_t size_st = 0;
    + 			buf = odb_read_object_peeled(the_repository->objects, &b->oid,
    +-						     OBJ_COMMIT, &size_st, &b->oid);
    +-			size = cast_size_t_to_ulong(size_st);
    ++						     OBJ_COMMIT, &size, &b->oid);
    + 		}
      		parse_from_commit(b, buf, size);
      		free(buf);
    - 	}
     @@ builtin/fast-import.c: static int parse_objectish(struct fast_import_state *state,
      		if (!oideq(&b->oid, &oe->idx.oid)) {
      			oidcpy(&b->oid, &oe->idx.oid);

Resolved: 915344c (Backport fix for now-flaky HTTP-auth tests (git-for-windows#6489), 2026-10-16)

preserved and staged the required curl_url lazy-loading shims

Range-diff
  • 1: 915344c ! 1: a9df4a8 Backport fix for now-flaky HTTP-auth tests (Backport fix for now-flaky HTTP-auth tests git#6489)

    @@ Commit message
         fast-track the same fix into Git for Windows.
     
      ## compat/lazyload-curl.c ##
    + remerge CONFLICT (add/add): Merge conflict in compat/lazyload-curl.c
    + index 6c576687b1..c361eab85c 100644
    + --- compat/lazyload-curl.c
    + +++ compat/lazyload-curl.c
     @@ compat/lazyload-curl.c: static curl_easy_setopt_pointer_type curl_easy_setopt_pointer_func;
      typedef CURLcode (*curl_easy_setopt_off_t_type)(CURL *curl, CURLoption opt, curl_off_t value);
      static curl_easy_setopt_off_t_type curl_easy_setopt_off_t_func;
      
    -+typedef CURLU *(*curl_url_type)(void);
    -+static curl_url_type curl_url_func;
    -+
    -+typedef void (*curl_url_cleanup_type)(CURLU *u);
    -+static curl_url_cleanup_type curl_url_cleanup_func;
    -+
    -+typedef CURLUcode (*curl_url_get_type)(const CURLU *u, CURLUPart what,
    -+				       char **part, unsigned int flags);
    -+static curl_url_get_type curl_url_get_func;
    -+
    -+typedef CURLUcode (*curl_url_set_type)(CURLU *u, CURLUPart what,
    -+				       const char *part, unsigned int flags);
    -+static curl_url_set_type curl_url_set_func;
    -+
    +-<<<<<<< 48cc0a854b (ci: bump actions/setup-python from 6 to 7)
    +-=======
    + typedef CURLU *(*curl_url_type)(void);
    + static curl_url_type curl_url_func;
    + 
    +@@ compat/lazyload-curl.c: typedef CURLUcode (*curl_url_set_type)(CURLU *u, CURLUPart what,
    + 				       const char *part, unsigned int flags);
    + static curl_url_set_type curl_url_set_func;
    + 
    +->>>>>>> ad514b3878 (Merge branch 'jk/http-curl-strip-creds')
      static char ssl_backend[64];
      
      static void lazy_load_curl(void)
    @@ compat/lazyload-curl.c: static void lazy_load_curl(void)
      	curl_easy_setopt_long_func = (curl_easy_setopt_long_type)curl_easy_setopt_func;
      	curl_easy_setopt_pointer_func = (curl_easy_setopt_pointer_type)curl_easy_setopt_func;
      	curl_easy_setopt_off_t_func = (curl_easy_setopt_off_t_type)curl_easy_setopt_func;
    -+
    -+	curl_url_func = (curl_url_type)load_function(libcurl, "curl_url");
    -+	curl_url_cleanup_func = (curl_url_cleanup_type)load_function(libcurl, "curl_url_cleanup");
    -+	curl_url_get_func = (curl_url_get_type)load_function(libcurl, "curl_url_get");
    -+	curl_url_set_func = (curl_url_set_type)load_function(libcurl, "curl_url_set");
    +-<<<<<<< 48cc0a854b (ci: bump actions/setup-python from 6 to 7)
    +-=======
    + 
    + 	curl_url_func = (curl_url_type)load_function(libcurl, "curl_url");
    + 	curl_url_cleanup_func = (curl_url_cleanup_type)load_function(libcurl, "curl_url_cleanup");
    + 	curl_url_get_func = (curl_url_get_type)load_function(libcurl, "curl_url_get");
    + 	curl_url_set_func = (curl_url_set_type)load_function(libcurl, "curl_url_set");
    +->>>>>>> ad514b3878 (Merge branch 'jk/http-curl-strip-creds')
      }
      
      struct curl_version_info_data *curl_version_info(CURLversion version)
    @@ compat/lazyload-curl.c: CURLcode curl_easy_setopt(CURL *curl, CURLoption opt, ..
      	va_end(ap);
      	return res;
      }
    -+
    -+CURLU *curl_url(void)
    -+{
    -+	return curl_url_func();
    -+}
    -+
    -+void curl_url_cleanup(CURLU *u)
    -+{
    -+	curl_url_cleanup_func(u);
    -+}
    -+
    -+CURLUcode curl_url_get(const CURLU *u, CURLUPart what,
    -+		       char **part, unsigned int flags)
    -+{
    -+	return curl_url_get_func(u, what, part, flags);
    -+}
    -+
    -+CURLUcode curl_url_set(CURLU *u, CURLUPart what,
    -+		       const char *part, unsigned int flags)
    -+{
    -+	return curl_url_set_func(u, what, part, flags);
    -+}
    +-<<<<<<< 48cc0a854b (ci: bump actions/setup-python from 6 to 7)
    +-=======
    + 
    + CURLU *curl_url(void)
    + {
    +@@ compat/lazyload-curl.c: CURLUcode curl_url_set(CURLU *u, CURLUPart what,
    + {
    + 	return curl_url_set_func(u, what, part, flags);
    + }
    +->>>>>>> ad514b3878 (Merge branch 'jk/http-curl-strip-creds')

To: d420916110 (ci: pin linux32 to ubuntu-24.04 to restore networking, 2026-10-25) (20e10cfaa4..d420916110)

Statistics

Metric Count
Total conflicts 2
Skipped (upstreamed) 0
Resolved surgically 2
Range-diff (click to expand)

dscho and others added 30 commits October 27, 2026 03:39
Although NTLM authentication is considered weak (extending even to
NTLMv2, which purportedly allows brute-forcing reasonably complex
8-character passwords in a matter of days, given ample compute
resources), it _is_ one of the authentication methods supported by
libcurl.

Note: The added test case *cannot* reuse the existing `custom_auth`
facility. The reason is that that facility is backed by an NPH script
("No Parse Headers"), which does not allow handling the 3-phase NTLM
authentication correctly (in my hands, the NPH script would not even be
called upon the Type 3 message, a "200 OK" would be returned, but no
headers, let alone the `git http-backend` output as payload). Having a
separate NTLM authentication script makes the exact workings clearer and
more readable, anyway.

Co-authored-by: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This will come in handy in the next commit.

Signed-off-by: JiSeop Moon <zcube@zcube.kr>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Bert Belder <bertbelder@gmail.com>
Continue the size_t evacuation. With buffer_is_binary() widened
in the prior commit, every consumer that the size flows into in
combine-diff.c is size_t-ready, so widen grab_blob()'s out-param
outright and move the matching locals at its three call sites
together. grab_blob()'s body collapses to a direct
odb_read_object(&size) since the bridge variable is no longer
needed.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Prep for dropping the cast_size_t_to_ulong() shim in
add_preferred_base() (pack-objects.c), and aligns the public API
with the size_t shape the rest of the tree topic is moving toward.

struct tree_desc.size stays unsigned int -- the on-disk tree format
hard-caps each tree at 4 GiB, so the field is intentionally narrow
and the assignment in init_tree_desc_internal() already truncated
unsigned long inputs the same way it now truncates size_t inputs.
The widening is purely about the call-side type-correctness; the
internal cap is unchanged.

All 30+ callers pass values that promote cleanly (unsigned long,
size_t, or smaller integer types).

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This implements the Windows-specific support code, because everything is
slightly different on Windows, even loading shared libraries.

Note: I specifically do _not_ use the code from
`compat/win32/lazyload.h` here because that code is optimized for
loading individual functions from various system DLLs, while we
specifically want to load _many_ functions from _one_ DLL here, and
distinctly not a system DLL (we expect libcurl to be located outside
`C:\Windows\system32`, something `INIT_PROC_ADDR` refuses to work with).
Also, the `curl_easy_getinfo()`/`curl_easy_setopt()` functions are
declared as vararg functions, which `lazyload.h` cannot handle. Finally,
we are about to optionally override the exact file name that is to be
loaded, which is a goal contrary to `lazyload.h`'s design.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since we are already walking our reachable objects using the path-walk API,
let's now collect lists of the paths that contribute most to different
metrics. Specifically, we care about

 * Number of versions.
 * Total size on disk.
 * Total inflated size (no delta or zlib compression).

This information can be critical to discovering which parts of the
repository are causing the most growth, especially on-disk size. Different
packing strategies might help compress data more efficiently, but the toal
inflated size is a representation of the raw size of all snapshots of those
paths. Even when stored efficiently on disk, that size represents how much
information must be processed to complete a command such as 'git blame'.

The exact disk size seems to be not quite robust enough for testing, as
could be seen by the `linux-musl-meson` job consistently failing, possibly
because of zlib-ng deflates differently: t8100.4(git survey
(default)) was failing with a symptom like this:

   TOTAL OBJECT SIZES BY TYPE
   ===============================================
   Object Type | Count | Disk Size | Inflated Size
   ------------+-------+-----------+--------------
  -    Commits |    10 |      1523 |          2153
  +    Commits |    10 |      1528 |          2153
         Trees |    10 |       495 |          1706
         Blobs |    10 |       191 |           101
  -       Tags |     4 |       510 |           528
  +       Tags |     4 |       547 |           528

This means: the disk size is unlikely something we can verify robustly.
Since zlib-ng seems to increase the disk size of the tags from 528 to
547, we cannot even assume that the disk size is always smaller than the
inflated size. We will most likely want to either skip verifying the
disk size altogether, or go for some kind of fuzzy matching, say, by
replacing `s/ 1[45][0-9][0-9] / ~1.5k /` and `s/ [45][0-9][0-9] / ~½k /`
or something like that.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`git survey` exposes its `--top` default via `survey.top` so that a
site or per-repository operator can switch the detail tables on once
and have every subsequent invocation include them. Mirror that
ergonomics for `git repo structure` so that, as `git survey`'s
functionality is folded into `git repo structure`, the configuration
side of the migration story stays equivalent.

Add a small `git_config_int` callback bound to `repo.structure.top`
and invoke it before `parse_options()`, so a `--top=<N>` on the
command line cleanly overrides the configured default (including
`--top=0` to opt out of the detail tables when configuration enables
them). Reject negative configured values with the same wording as the
command-line guard, since `git_config_int()` happily returns negative
integers.

Document the new variable in a fresh `Documentation/config/repo.adoc`
and wire it into the alphabetical includes in `Documentation/config.adoc`
between `repack.adoc` and `rerere.adoc`. Cover the precedence
behaviour with a t1901 test: a configured value enables the tables by
default, and a command-line `--top=0` suppresses them again.

Note that the reported paths respect the `core.quotePath` setting.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This comment has been true for the longest time; The combination of the
two preceding commits made it incorrect, so let's drop that comment.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NTLM authentication is relatively weak. This is the case even with the
default setting of modern Windows versions, where NTLMv1 and LanManager
are disabled and only NTLMv2 is enabled: NTLMv2 hashes of even
reasonably complex 8-character passwords can be broken in a matter of
days, given enough compute resources.

Even worse: On Windows, NTLM authentication uses Security Support
Provider Interface ("SSPI"), which provides the credentials without
requiring the user to type them in.

Which means that an attacker could talk an unsuspecting user into
cloning from a server that is under the attacker's control and extracts
the user's NTLMv2 hash without their knowledge.

For that reason, let's disallow NTLM authentication by default.

NTLM authentication is quite simple to set up, though, and therefore
there are still some on-prem Azure DevOps setups out there whose users
and/or automation rely on this type of authentication. To give them an
escape hatch, introduce the `http.<url>.allowNTLMAuth` config setting
that can be set to `true` to opt back into using NTLM for a specific
remote repository.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `git_terminal_prompt()` function expects the terminal window to be
attached to a Win32 Console. However, this is not the case with terminal
windows other than `cmd.exe`'s, e.g. with MSys2's own `mintty`.

Non-cmd terminals such as `mintty` still have to have a Win32 Console
to be proper console programs, but have to hide the Win32 Console to
be able to provide more flexibility (such as being resizeable not only
vertically but also horizontally). By writing to that Win32 Console,
`git_terminal_prompt()` manages only to send the prompt to nowhere and
to wait for input from a Console to which the user has no access.

This commit introduces a function specifically to support `mintty` -- or
other terminals that are compatible with MSys2's `/dev/tty` emulation. We
use the `TERM` environment variable as an indicator for that: if the value
starts with "xterm" (such as `mintty`'s "xterm_256color"), we prefer to
let `xterm_prompt()` handle the user interaction.

The most prominent user of `git_terminal_prompt()` is certainly
`git-remote-https.exe`. It is an interesting use case because both
`stdin` and `stdout` are redirected when Git calls said executable, yet
it still wants to access the terminal.

When running inside a `mintty`, the terminal is not accessible to the
`git-remote-https.exe` program, though, because it is a MinGW program
and the `mintty` terminal is not backed by a Win32 console.

To solve that problem, we simply call out to the shell -- which is an
*MSys2* program and can therefore access `/dev/tty`.

Helped-by: nalla <nalla@hamal.uberspace.de>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is a known issue that a rename() can fail with an "Access denied"
error at times, when copying followed by deleting the original file
works. Let's just fall back to that behavior.

Signed-off-by: JiSeop Moon <zcube@zcube.kr>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, symbolic links actually have a type depending on the target:
it can be a file or a directory.

In certain circumstances, this poses problems, e.g. when a symbolic link
is supposed to point into a submodule that is not checked out, so there
is no way for Git to auto-detect the type.

To help with that, we will add support over the course of the next
commits to specify that symlink type via the Git attributes. This
requires an index_state, though, something that Git for Windows'
`symlink()` replacement cannot know about because the function signature
is defined by the POSIX standard and not ours to change.

So let's introduce a helper function to create symbolic links that
*does* know about the index_state.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Continue the size_t evacuation. textconv_object() fills its
out-parameter from fill_textconv()'s size_t return through an
unsigned long*; widen the API to match, then take advantage of the
new shape where callers can.

cat-file's 'c' and batch-mode 'c' branches lose their size_ul
bridge variables (one site becomes a direct call, the other
collapses an if/else into a single negated condition that reads as
"try textconv, fall back to a raw read").

blame.c likewise drops the file_size_st bridge in fill_origin_blob()
and hoists final_buf_size_st to bracket both branches in
setup_scoreboard(). The latter keeps a cast_size_t_to_ulong() shim
because struct blame_scoreboard.final_buf_size is still unsigned
long; that field is its own topic.

log.c just widens its local from unsigned long to size_t.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With init_tree_desc() widened in the prior commit, the
size_t-returning odb_read_object_peeled() call in
add_preferred_base() and odb_read_object() call in pbase_tree_get()
can both flow straight through to init_tree_desc() and into the
pbase_tree_cache. Widen pbase_tree_cache.tree_size and the two
local size variables to size_t, drop the size_st bridges, and drop
the two cast_size_t_to_ulong() shims.

This was the last pair of cast_size_t_to_ulong() call sites in
builtin/pack-objects.c, completing the >4 GiB-objects work in that
file that this branch and its predecessors have been pursuing.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The previous commits introduced a compile-time option to load libcurl
lazily, but it uses the hard-coded name "libcurl-4.dll" (or equivalent
on platforms other than Windows).

To allow for installing multiple libcurl flavors side by side, where
each supports one specific SSL/TLS backend, let's first look whether
`libcurl-<backend>-4.dll` exists, and only use `libcurl-4.dll` as a fall
back.

That will allow us to ship with a libcurl by default that only supports
the Secure Channel backend for the `https://` protocol. This libcurl
won't suffer from any dependency problem when upgrading OpenSSL to a new
major version (which will change the DLL name, and hence break every
program and library that depends on it).

This is crucial because Git for Windows relies on libcurl to keep
working when building and deploying a new OpenSSL package because that
library is used by `git fetch` and `git clone`.

Note that this feature is by no means specific to Windows. On Ubuntu,
for example, a `git` built using `LAZY_LOAD_LIBCURL` will use
`libcurl.so.4` for `http.sslbackend=openssl` and `libcurl-gnutls.so.4`
for `http.sslbackend=gnutls`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The 'git survey' builtin provides several detail tables, such as "top
files by on-disk size". The size of these tables defaults to 10,
currently.

Allow the user to specify this number via a new --top=<N> option or the
new survey.top config key.

Signed-off-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
`git survey` started life as an experimental scale-measurement tool;
the preceding commits give `git repo structure` the path-level detail
tables and ref-scoping mechanism that were `git survey`'s main draw,
so the two now overlap substantially. Plan the migration explicitly:
add a short notice at the top of the description making clear which
of `git survey`'s knobs map to which `git repo structure` option, and
state that a future release will turn `git survey` into a thin shim
over `git repo structure`.

Putting the notice in the description (rather than only the synopsis)
ensures it shows up in `git help survey` rendering before the reader
sees any option specifics, so an operator skimming the page learns
about the replacement before adopting any survey-specific flags.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Commit 2406bf5 (Win32: detect unix socket support at runtime,
2024-04-03) introduced a runtime detection for whether the operating
system supports unix sockets for Windows, but a mistake snuck into the
tests. When building and testing Git without NO_UNIX_SOCKETS we
currently skip t0301-credential-cache on Windows if unix sockets are
supported and run the tests if they aren't.

Flip that logic to actually work the way it was intended.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The new default of Git is to disable NTLM authentication by default.

To help users find the escape hatch of that config setting, should they
need it, suggest it when the authentication failed and the server had
offered NTLM, i.e. if re-enabling it would fix the problem.

Helped-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Accessing the Windows console through the special CONIN$ / CONOUT$ devices
doesn't work properly for non-ASCII usernames an passwords.

It also doesn't work for terminal emulators that hide the native console
window (such as mintty), and 'TERM=xterm*' is not necessarily a reliable
indicator for such terminals.

The new shell_prompt() function, on the other hand, works fine for both
MSys1 and MSys2, in native console windows as well as mintty, and properly
supports Unicode. It just needs bash on the path (for 'read -s', which is
bash-specific).

On Windows, try to use the shell to read from the terminal. If that fails
with ENOENT (i.e. bash was not found), use CONIN/OUT as fallback.

Note: To test this, create a UTF-8 credential file with non-ASCII chars,
e.g. in git-bash: 'echo url=http://täst.com > cred.txt'. Then in git-cmd,
'git credential fill <cred.txt' works (shell version), while calling git
without the git-wrapper (i.e. 'mingw64\bin\git credential fill <cred.txt')
mangles non-ASCII chars in both console output and input.

Signed-off-by: Karsten Blees <blees@dcon.de>
In preparation for making this function a bit more complicated (to allow
for special-casing the `ContainerMappedDirectories` in Windows
containers, which look like a symbolic link, but are not), let's move it
out of the header.

Signed-off-by: JiSeop Moon <zcube@zcube.kr>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, symbolic links have a type: a "file symlink" must point at
a file, and a "directory symlink" must point at a directory. If the
type of symlink does not match its target, it doesn't work.

Git does not record the type of symlink in the index or in a tree. On
checkout it'll guess the type, which only works if the target exists
at the time the symlink is created. This may often not be the case,
for example when the link points at a directory inside a submodule.

By specifying `symlink=file` or `symlink=dir` the user can specify what
type of symlink Git should create, so Git doesn't have to rely on
unreliable heuristics.

Signed-off-by: Bert Belder <bertbelder@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It seems to be not exactly rare on Windows to install NTFS junction
points (the equivalent of "bind mounts" on Linux/Unix) in worktrees,
e.g. to map some development tools into a subdirectory.

In such a scenario, it is pretty horrible if `git clean -dfx` traverses
into the mapped directory and starts to "clean up".

Let's just not do that. Let's make sure before we traverse into a
directory that it is not a mount point (or junction).

This addresses git-for-windows#607

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Same theme as the preceding pack-objects series: get_size_by_pos()
returns an unsigned long but reads its size out of packed_object_info()
/ odb_read_object_info_extended() via a size_t out-parameter, so on
Windows it would silently truncate the very sizes filter_bitmap_blob_limit()
then compares against the --filter=blob:limit threshold to decide which
blobs to elide from the bitmap-backed traversal. Drop the
cast_size_t_to_ulong() and return size_t directly.

The two callers' limit comparison promotes to size_t cleanly. limit
itself stays unsigned long; it is part of a filter API ripple of its
own.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Continue the size_t evacuation. The struct field already receives
its writes from a size_t-shaped source (xsize_t(st.st_size),
strbuf.len, fill_textconv()'s return, odb_read_object_info_extended()
via oi.sizep), so on Windows it was already truncating anything
past 4 GiB silently on the strbuf and textconv paths and loudly
through cast_size_t_to_ulong() on the odb path. Switch the field
to size_t.

In diff_populate_filespec(), point oi.sizep at the field directly
and drop both cast_size_t_to_ulong() shims and the size_st bridge
they fed.

Downstream consumers that still read .size into unsigned long
locals will now silently narrow on Windows where the field exceeds
4 GiB. Each of those is its own follow-up; the writer side is the
prerequisite for ever putting a >4 GiB value in the field in the
first place.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Final piece of the tree topic. struct tree.size already receives
its values from size_t-shaped sources (odb_read_object() in
repo_parse_tree_gently() and in reflog.c::tree_is_complete()),
so on Windows it was already silently truncating anything past
4 GiB. Switch the field and parse_tree_buffer()'s size parameter
to size_t.

All readers feed tree->size into init_tree_desc(), which was
widened earlier in this topic; the existing parse_object_buffer()
caller in object.c keeps its unsigned long parameter, which
promotes cleanly.

Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
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 <dl3@pale-eds.co.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mathstuf and others added 30 commits October 27, 2026 03:41
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 <mathstuf@gmail.com>
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 <johannes.schindelin@gmx.de>
…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 <johannes.schindelin@gmx.de>
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 <vdye@github.com>
Helped-by: Matthew John Cheetham <mjcheetham@outlook.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows accepts pull requests; Core Git does not. Therefore we
need to adjust the template (because it only matches core Git's
project management style, not ours).

Also: direct Git for Windows enhancements to their contributions page,
space out the text for easy reading, and clarify that the mailing list
is plain text, not HTML.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 <vdye@github.com>
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 <johannes.schindelin@gmx.de>
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 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>
This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.

Helped-by: Sven Strickroth <email@cs-ware.de>
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>
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 <johannes.schindelin@gmx.de>
…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 <johannes.schindelin@gmx.de>
Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…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] <support@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
…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 <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
We haven't been on Gitter in quite a while. Let's remove the misleading
badge.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 <johannes.schindelin@gmx.de>
When replacing `dirname`, elevation is required, otherwise the command
will fail with:

  + ln -sfT /usr/bin/gnudirname /usr/bin/dirname
  ln: failed to create symbolic link '/usr/bin/dirname': Already exists

as observed in
https://github.com/git-for-windows/git/actions/runs/40223871341/job/121274294974?pr=6473#step:3:909

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The linux32 job fails DNS resolution before checkout because Docker
29.4.2's seccomp profile on Ubuntu 26.04 blocks socketcall in i386 glibc
containers. Ubuntu 24.04 avoids this host-side regression.

actions/runner-images#14790

Assisted-by: GPT-6.1 Sol
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.