git/Makefile, branch next

Merge branch 'mm/git-url-parse' into next

2026-05-15T01:46:53Z

The internal URL parsing logic has been made accessible via a new subcommand "git url-parse". * mm/git-url-parse: t9904: add tests for the new url-parse builtin doc: describe the url-parse builtin builtin: create url-parse command urlmatch: define url_parse function url: return URL_SCHEME_UNKNOWN instead of dying url: move scheme detection to URL header/source url: move url_is_local_not_ssh to url.h connect: rename enum protocol to url_scheme

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

2026-05-13T03:21:27Z

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 next

2026-05-13T03:21:26Z

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

Merge branch 'kh/name-rev-custom-format' into next

2026-05-12T02:07:48Z

A new builtin "git format-rev" is introduced for pretty formatting one revision expression per line or commit object names found in running text. * kh/name-rev-custom-format: format-rev: introduce builtin for on-demand pretty formatting name-rev: make dedicated --annotate-stdin --name-only test name-rev: factor code for sharing with a new command name-rev: run clang-format before factoring code name-rev: wrap both blocks in braces

format-rev: introduce builtin for on-demand pretty formatting

2026-05-12T00:09:51Z

Introduce a new builtin for pretty formatting one revision expression per line or commit object names found in running text. Sometimes you want to format commits. Most of the time you’re walking the graph, e.g. getting a range of commits like `master..topic`. That’s a job for git-log(1). But there are times when you want to format commits that you encounter on demand: • Full hashes in running text that you might want to pretty-print • git-last-modified(1) outputs full hashes that you can do the same with • git-cherry(1) has `-v` for commit subject, but maybe you want something else? But now you can’t use git-log(1), git-show(1), or git-rev-list(1): • You can’t feed commits piecemeal to these commands, one input for one output; they block until standard in is closed • You can’t feed a list of possibly duplicate commits, like the output of git-last-modified(1); they effectively deduplicate the output Beyond these two points there’s also the input massage problem: you cannot feed mixed input (revisions mixed with arbitrary text). One might hope that git-cat-file(1) can save us. But it doesn’t support pretty formats. But there is one command that already both handles revisions as arguments, revisions on standard input, and even revisions mixed in with arbitrary text. Namely git-name-rev(1): the command for outputting symbolic names for commits. We made some room in `builtin/name-rev.c` two commits ago. Let’s now add this new git-format-rev(1) command. Taking inspiration from git-name-rev(1), there are two modes: • revs: like git-name-rev(1) in argv mode, but one revision per line on standard in • text: like git-name-rev(1) with `--annotate-stdin` *** We need to add this command to the exception list in `t/t1517-outside-repo.sh` because it uses “EXPERIMENTAL!” in the usage line. Helped-by: Phillip Wood Helped-by: Ramsay Jones Helped-by: Junio C Hamano Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

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: drop the build-system plumbing for nedmalloc

2026-05-09T02:19:23Z

With the previous commit removing every opt-in, the build-system plumbing for nedmalloc has nothing left to switch on. Remove it so that the upcoming deletion of the compat/nedmalloc/ tree is a pure file removal. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

builtin: create url-parse command

2026-05-06T00:48:28Z

Git commands can accept a rather wide variety of URLs syntaxes. The range of accepted inputs might expand even more in the future. This makes the parsing of URL components difficult since standard URL parsers cannot be used. Extracting the components of a git URL would require implementing all the schemes that git itself supports, not to mention tracking its development continuously in case new URL schemes are added. The url-parse builtin command is designed to solve this problem by exposing git's native URL parsing facilities as a plumbing command. Other programs can then call upon git itself to parse the git URLs and extract their components. This should be quite useful for scripts. Signed-off-by: Matheus Afonso Martins Moreira Signed-off-by: Junio C Hamano

Merge branch 'bc/rust-by-default' into next

2026-04-23T02:08:25Z

Rust support is enabled by default (but still allows opting out) in some future version of Git. * bc/rust-by-default: Enable Rust by default Linux: link against libdl ci: install cargo on Alpine docs: update version with default Rust support

Revert "Merge branch 'pt/fsmonitor-linux' into next"

2026-04-14T20:33:08Z

This reverts commit 37fa47889d5763ec3876606fb475bb68af9fd90f, reversing changes made to 289fcba08108603e2370294eeff384fb2090ed6a, as the tests in the topic was pointed out to be seriously broken. cf.