git/compat, branch jch

Merge branch 'ob/more-repo-config-values' into jch

2026-05-17T13:58:51Z

* ob/more-repo-config-values: env: move "warn_on_object_refname_ambiguity" into `struct repo_config_values` env: move "sparse_expect_files_outside_of_patterns" into `repo_config_values` env: move "core_sparse_checkout_cone" into `struct repo_config_values` environment: move "precomposed_unicode" into `struct repo_config_values` environment: move "pack_compression_level" into `struct repo_config_values` environment: move `zlib_compression_level` into `struct repo_config_values` environment: move "check_stat" into `struct repo_config_values` environment: move "trust_ctime" into `struct repo_config_values`

Merge branch 'js/mingw-no-nedmalloc' into jch

2026-05-17T13:58:41Z

Stop using unmaintained custom allocator in Windows build which was the last user of the code. * js/mingw-no-nedmalloc: mingw: remove the vendored compat/nedmalloc/ subtree mingw: drop the build-system plumbing for nedmalloc mingw: stop using nedmalloc

Merge branch 'js/objects-larger-than-4gb-on-windows' into jch

2026-05-17T13:58:41Z

Update code paths that assumed "unsigned long" was long enough for "size_t". * js/objects-larger-than-4gb-on-windows: ci: run expensive tests on push builds to integration branches t5608: mark >4GB tests as EXPENSIVE test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1 test-tool synthesize: precompute pack for 4 GiB + 1 test-tool synthesize: use the unsafe hash for speed t5608: add regression test for >4GB object clone test-tool: add a helper to synthesize large packfiles delta, packfile: use size_t for delta header sizes odb, packfile: use size_t for streaming object sizes git-zlib: handle data streams larger than 4GB index-pack, unpack-objects: use size_t for object size

test-tool: add a helper to synthesize large packfiles

2026-05-09T02:25:32Z

To test Git's behavior with very large pack files, we need a way to generate such files quickly. A naive approach using only readily-available Git commands would take over 10 hours for a 4GB pack file, which is prohibitive. Side-stepping Git's machinery and actual zlib compression by writing uncompressed content with the appropriate zlib header makes things much faster. The fastest method using this approach generates many small, unreachable blob objects and takes about 1.5 minutes for 4GB. However, this cannot be used because we need to test git clone, which requires a reachable commit history. Generating many reachable commits with small, uncompressed blobs takes about 4 minutes for 4GB. But this approach 1) does not reproduce the issues we want to fix (which require individual objects larger than 4GB) and 2) is comparatively slow because of the many SHA-1 calculations. The approach taken here generates a single large blob (filled with NUL bytes), along with the trees and commits needed to make it reachable. This takes about 2.5 minutes for 4.5GB, which is the fastest option that produces a valid, clonable repository with an object large enough to trigger the bugs we want to test. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: remove the vendored compat/nedmalloc/ subtree

2026-05-09T02:20:12Z

The previous two commits stopped opting into nedmalloc on Windows and stripped out the build-system plumbing that referenced it; the compat/nedmalloc/ subtree now has no callers and no consumers in the build, so retire it from the tree. Note that this patch is larger than can be sent via the mailing list, and was originally sent in three-pieces and merged back on the receiving end. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: optionally use legacy (non-POSIX) delete semantics

2026-05-08T00:53:12Z

At some point between Windows 10 Build 17134.1304 and Build 18363.657, the default behavior of `DeleteFileW()` was changed to use POSIX semantics (https://stackoverflow.com/a/60512798). Under those semantics, a file can be deleted even when another process holds an active `MapViewOfFile` view on it: the directory entry is removed immediately, but the underlying data persists until the last handle is closed. On older Windows versions (and Windows 10 builds before that change), `DeleteFileW()` uses legacy semantics where deletion fails outright if any process holds a file mapping. To allow testing code paths that depend on the legacy behavior, introduce a `GIT_TEST_LEGACY_DELETE` environment variable. When set, `mingw_unlink()` uses `SetFileInformationByHandle()` with `FileDispositionInfo` (the non-POSIX variant) instead of `DeleteFileW()`, forcing legacy delete semantics regardless of the Windows version. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

environment: move "precomposed_unicode" into `struct repo_config_values`

2026-04-25T10:35:41Z

The `core.precomposeunicode` configuration is currently stored in the global variable `precomposed_unicode`, which makes it shared across repository instances within a single process. Store it instead in `repo_config_values`, where eagerly‑parsed repository configuration lives. `core.precomposeunicode` is parsed eagerly because it controls Unicode path normalization on macOS, a fundamental filesystem‑level behavior that many operations depend on; a lazy parse could lead to inconsistent results and hamper libification. This preserves the existing behavior while tying the value to the repository from which it was read, avoiding cross‑ repository state leakage and continuing the effort to reduce reliance on global configuration state. Change the type of the field from `int` to `bool` since it is parsed as a boolean value. Update all references to use `repo_config_values()`. Mentored-by: Christian Couder Mentored-by: Usman Akinyemi Signed-off-by: Olamide Caleb Bello Signed-off-by: Junio C Hamano

Revert "compat/posix: introduce writev(3p) wrapper"

2026-04-09T21:48:24Z

This reverts commit 3b9b2c2a29a1d529ca9884fa0a6529f6e2496abe; let's not use writev() for now.

compat/winansi: drop pre-Vista workaround

2026-04-06T17:06:22Z

1edeb9a (Win32: warn if the console font doesn't support Unicode, 2014-06-10) introduced both code to detect the current console font on Windows Vista and newer and a fallback for older systems to detect the default console font and issue a warning if that font doesn't support unicode. Since we haven't supported any Windows older than Vista in almost a decade, we don't need to keep the workaround. Signed-off-by: Matthias Aßhauer Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

unify and bump _WIN32_WINNT definition to Windows 8.1

2026-04-06T17:06:20Z

Git for Windows doesn't support anything prior to Windows 8.1 since 2.47.0 and Git followed along with commits like ce6ccba (mingw: drop Windows 7-specific work-around, 2025-08-04). There is no need to pretend to the compiler that we still support Windows Vista, just to lock us out of easy access to newer APIs. There is also no need to have conflicting and unused definitions claiming we support some versions of Windows XP or even Windows NT 4.0. Bump all definitions of _WIN32_WINNT to a realistic value of Windows 8.1. This will also simplify code for a followup commit that will improve cpu core detection on multi-socket systems. Signed-off-by: Matthias Aßhauer Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano