* What's cooking in git.git (Sep 2026, #08)
@ 2026-09-22 0:11 Junio C Hamano
2026-09-22 8:11 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
2026-09-22 13:25 ` Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Johannes Schindelin
0 siblings, 2 replies; 21+ messages in thread
From: Junio C Hamano @ 2026-09-22 0:11 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and is a candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all. They may be annotated with a URL
to a message that raises issues but they are by no means exhaustive.
A topic without enough support may be discarded after a long period
of no activity (of course, it can be resubmitted when new interest
arises).
Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
the final Git 2.56 release, but otherwise I do not expect any new
feature topics to be ready before the final, so most of the
in-flight topics will stay cooking in 'next' until then. As
discussed at the Git Contributors' Summit, the version after the
upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
year.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* tz/doc-pack-refs-and-refs-fixes (2026-09-15) 2 commits
(merged to 'next' on 2026-09-16 at 127f3b13fa)
+ doc/refs: backtick-quote commands and options consistently
+ doc/pack-refs: convert synopsis and options to new style
Doc updates.
Graduated to 'master'.
source: <20260912191509.844954-1-tmz@pobox.com>
* yt/pathspec-negative-prefix (2026-09-14) 2 commits
(merged to 'next' on 2026-09-16 at f4f244ea28)
+ dir: preserve pathspec prefix optimization with leading excludes
+ dir: do not apply prefix to negative pathspecs
+ Merge branch 'jc/pathspec-match-const' into yt/pathspec-negative-prefix
The pathspec matching logic has been updated to avoid out-of-bounds
memory accesses when a negative pathspec is shorter than the common
prefix of positive pathspecs.
Graduated to 'master'.
source: <7CB757FB-1F2D-4EE6-8C31-8C2CD6D42397@ytausch.de>
--------------------------------------------------
[New Topics]
* rr/upload-pack-swap-shallow-wanted-ref (2026-09-16) 1 commit
- upload-pack: swap wanted-ref/shallow-info responses
The server-side protocol v2 response order for 'wanted-refs' and
'shallow-info' has been swapped to match the client's expectation,
fixing a fetch failure when the server has 'uploadpack.allowRefInWant'
enabled and the client performs a shallow fetch.
Will merge to 'next'.
source: <20260916203221.5265-1-royceremer@gmail.com>
* bs/runtime-prefix-obsd-getexecpath (2026-09-16) 1 commit
- exec_cmd: RUNTIME_PREFIX on OpenBSD systems
Git on OpenBSD historically lacked an authoritative mechanism to
resolve its executable path, as it doesn't support the
KERN_PROC_PATHNAME sysctl. With OpenBSD 8.0 introducing
getexecpath(3), it is now utilized to provide proper RUNTIME_PREFIX
resolution instead of relying on argv[0] fallback.
Waiting for response.
cf. <xmqq4ifio83d.fsf@gitster.g>
source: <aqthQ3u4eW1wHCn7@humpty.home.comstyle.com>
* js/coverity-fixes (2026-09-17) 7 commits
- test-read-midx: check midx_fill_entry() result
- oss-fuzz: handle reftable iterator initialization failures
- t/unit-tests: check reftable iterator initialization
- rerere: do not record failed conflict resolution data
- midx: validate incremental MIDX pack IDs
- gpg-interface: make signature-prefix matching length-aware
- wrapper: guard writev_in_full() against signed overflow
Assorted fixes for code paths that are not careful with boundary and
error conditions.
Will merge to 'next'?
cf. <xmqq5x03u0xz.fsf@gitster.g>
cf. <xmqq1parorz4.fsf@gitster.g>
source: <pull.2231.git.1789667556.gitgitgadget@gmail.com>
* yt/winansi-die-lasterr-fix (2026-09-20) 1 commit
- compat/winansi: fix die_lasterr() argument formatting
The error reporting machinery in the WinANSI compatibility layer has
been simplified to pass the exact Windows error code and correctly
format arguments for fatal errors.
Waiting for response.
cf. <xmqqwlsemsjt.fsf@gitster.g>
source: <20260921062114.14450-1-yqtian668@gmail.com>
* hd/diff-no-index-reverse-fix (2026-09-18) 1 commit
- diff --no-index: fix -R with file/directory conflicts
A bug in git diff --no-index that mishandled reverse (-R) output
when conflicts existed between a file and a directory has been
fixed.
Will merge to 'next'?
cf. <9b97c14b-1d25-409b-a72c-d8caf298bf87@web.de>
cf. <0c82d50e-f2c0-4db6-ade8-7a403cac73da@intel.com>
source: <pull.2232.git.1789715946888.gitgitgadget@gmail.com>
* js/gitlab-ci-windows-rust (2026-09-19) 4 commits
- ci(gitlab,windows): provide GNU Rust's host-linker support
- ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
- ci(gitlab,windows): preserve exclusions during dependency setup
- ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
The Windows GitLab CI job has been updated to provision and use the
GNU Rust toolchain for MinGW builds, fixing job failures caused by
incomplete Rust setup and missing linker support.
Will merge to 'next'?
cf. <CAOLa=ZQkJui77Xz2HL4sAWsaYLAzU6EPvBk+RzKkKxoiY_8aKw@mail.gmail.com>
source: <pull.2233.git.1789819933.gitgitgadget@gmail.com>
--------------------------------------------------
[Cooking]
* jc/advice-config-set-global (2026-09-14) 1 commit
- advice: give cut-and-pasteable advice to squelch
The advice subsystem has been updated to suggest using the
'--global' option when recommending a command snippet to squelch
future advice messages, since global configuration is generally
more appropriate for user-level preferences than per-repository
settings.
Needs review.
source: <xmqq33vb4hma.fsf@gitster.g>
* sg/precompile-git-compat-util (2026-09-14) 4 commits
(merged to 'next' on 2026-09-21 at 68acceee5b)
+ Makefile: precompile "git-compat-util.h"
+ Makefile: reintroduce REFTABLE_OBJS
+ cmake: remove any "$(*_OBJS)" variables when parsing Makefile for sources
+ Makefile: remove XDIFF_OBJS initialization
The 'Makefile' has been taught to precompile 'git-compat-util.h' to
speed up overall compilation, while excluding sources that do not
include the compatibility header.
Will cook in 'next'.
source: <20260915060952.569535-1-szeder.dev@gmail.com>
* of/commit-reach-repo-awareness (2026-09-16) 1 commit
- commit-reach: parse commits in the given repository
The can_all_from_reach() and can_all_from_reach_with_flag()
functions have been updated to accept a repository context,
preventing bugs where submodule merging incorrectly reads from the
superproject's commit-graph.
Will merge to 'next'.
source: <20260916134632.1424829-1-orestisflo@gmail.com>
* hn/range-diff-matched-only (2026-09-15) 1 commit
- range-diff: add --matched-only to skip one-sided commits
The 'git range-diff' command has been augmented with a
'--matched-only' option to skip commits that are only present on
one side, allowing users to easily focus on only the commits that
have been retained.
Needs review.
source: <pull.2401.v3.git.git.1789458703432.gitgitgadget@gmail.com>
* jc/cocci-free-updates (2026-09-11) 2 commits
(merged to 'next' on 2026-09-16 at 35b8bafa06)
+ cocci: FREE_AND_NULL(E) is safe to call on NULL
+ cocci: remove risky "if (!E) free(E)" conversion
Updates to Coccinelle semantic patches to correctly handle the
'FREE_AND_NULL()' macro and avoid generating broken transformations
for negated pointer checks.
Will cook in 'next'.
cf. <96aca004-0df4-4e21-b60a-0288239122cc@web.de>
source: <xmqqld978mok.fsf@gitster.g>
source: <xmqqh5jv8m4w.fsf@gitster.g>
* jt/object-file-batch-fsync-fix (2026-09-13) 2 commits
- object-file: flush transaction packfile before migrating objects
- object-file: lift ODB reprepare out of packfile flush
When 'core.fsyncMethod' is set to 'batch', the ODB transaction
failed to properly flush large blob packfiles residing in the
temporary directory before migrating the directory's contents to the
main object store. The execution sequence has been corrected by
performing the packfile flush before the temporary directory
migration, averting failure.
Waiting for review.
cf. <CAOLa=ZRCyowPgMABwsQBYTbW1cEf8PBBSszOEYQ4TKwLVKQfFA@mail.gmail.com>
cf. <aqkGPcJdw3QagN0B@jtobler--20250820-SHC54>
source: <cover.1789328612.git.jltobler@gmail.com>
* ak/refs-files-root-ref-lock (2026-09-11) 1 commit
(merged to 'next' on 2026-09-16 at c8568ea3e1)
+ refs/files: avoid packed-refs lock for root ref deletion
The files backend has been updated to avoid unconditionally locking
the 'packed-refs' file when deleting a root ref (which are never
packed).
Will cook in 'next'.
cf. <aqeLMG7lTJy3bM-h@pks.im>
source: <20260912014609.535922-1-skariel@gmail.com>
* tb/rerere-wait-for-merge-rr-lock (2026-09-14) 2 commits
- rerere: go on at a conflict when the lock stays busy
- rerere: wait for MERGE_RR.lock, and let the gc skip it
Instead of failing to record conflicts to be resolved immediately,
wait while "rerere gc" is ongoing.
Needs review.
source: <pull.2214.v4.git.1789373061.gitgitgadget@gmail.com>
* pp/midx-write-skip-empty (2026-09-08) 1 commit
- midx-write: skip writes with no object entries
The `git multi-pack-index write` command has been updated to
silently return success when there are no object entries to index.
This avoids writing empty `multi-pack-index` layers, which
previously caused subsequent incremental midx writes using the
`--bitmap` option to fail when attempting to load the missing
reverse index.
Waiting for review.
cf. <aqAkfGZtLJ97nG1m@com-79390>
cf. <CAOWp8q5UqPrJQosjypdcq=KX1TKcVenAOoZUYfTBDKbRUwazTw@mail.gmail.com>
source: <eef33827000cf106544174ed000129c2989af1cd.1788851232.git.pia@pierre.co>
* jk/merge-ll-tempfile-cleanup (2026-09-11) 3 commits
- merge-ll: use tempfile API for external driver files
- merge-ll: catch close() errors when writing external tempfiles
- merge-ll: use strbuf to read back external merge result
The external merge driver in 'git merge' now uses the tempfile API
to create its temporary files. This ensures that these temporaries
are reliably cleaned up even when the merge driver or its parent Git
process is terminated abruptly.
Expecting a reroll.
cf. <20260914165350.GA32247@peff.net>
source: <20260911171044.GA1609692@coredump.intra.peff.net>
* mh/rust-crate-subdir (2026-09-16) 1 commit
- move rust gitcore crate to a different subdirectory
The Rust code and its 'Cargo.toml' file have been moved from the
top-level repository root and 'src/' directory into a dedicated
'rust/' subdirectory. This avoids confusing Cargo's packaging
mechanism when the Git repository is included as a submodule in
other Rust projects.
Waiting for review.
cf. <yc4bgjoyxnm6o7q4gwols4d6zvdrq3ydw2c65wjdwof3hjyde6@2osv37jtuxx3>
source: <20260917060415.2986259-1-mh@glandium.org>
* ps/ref-storage-format (2026-09-09) 13 commits
(merged to 'next' on 2026-09-16 at 8937a6240b)
+ setup: allow "--ref-storage-format=" to specify a payload
+ setup: rename "init.defaultRefFormat" to "init.defaultRefStorageFormat"
+ t: rename GIT_TEST_DEFAULT_REF_FORMAT
+ setup: rename ref storage format environment variables
+ setup: refactor how we configure the ref storage format
+ refs: expose function to parse reference URIs
+ help: rename "default-ref-format" to "default-ref-storage-format"
+ builtin/rev-parse: rename "--show-ref-format" to "--show-ref-storage-format"
+ builtin/submodule: rename "--ref-format=" to "--ref-storage-format="
+ builtin/refs: rename "--ref-format=" to "--ref-storage-format="
+ builtin/clone: rename "--ref-format=" to "--ref-storage-format="
+ builtin/init: rename "--ref-format=" to "--ref-storage-format="
+ parse-options: allow for hidden aliases
The terminology regarding reference storage formats has been unified
across command-line options, environment variables, configuration
variables, and source code, standardizing on the phrase "ref storage
format" (e.g., `--ref-storage-format`, `'GIT_REF_STORAGE_FORMAT'`).
Additionally, the `--ref-storage-format` option has been updated to
accept payloads in the form `<format>://<payload>`.
Will cook in 'next'.
cf. <CAOLa=ZRxXimh8W-QBJB3VhbHOZWMEfWXB0ST0a=dOi+PNiR6sQ@mail.gmail.com>
cf. <5e062976-d584-496d-84e0-e4b59c8f6876@gmail.com>
source: <20260909-b4-pks-unify-ref-storage-format-v3-0-ca041fb40ad8@pks.im>
* ta/command-list-guides-sync-lint (2026-09-10) 2 commits
- lint-docs: check the guide list in command-list.txt
- command-list.txt: add gitformat-loose(5) and gitpacking(7)
- Merge branch 'kh/doc-datamodel' into ta/command-list-guides-sync-lint
A new linter test has been added to Documentation/lint-manpages.sh
to ensure that all non-command manual pages (guides and developer
interfaces) listed in Documentation/Makefile are present in
command-list.txt, replacing an older comment that reminded
developers to keep them in sync.
Needs review.
cf. <xmqq1pb2s33e.fsf@gitster.g>
source: <20260910194351.20809-1-taahol@utu.fi>
* ap/var-broken-down-idents (2026-09-14) 1 commit
- var: support broken-down idents, signing key, multiple args, and -z
The 'git var' command has been extended to expose individual
identity components ('GIT_AUTHOR_NAME', etc.) and the commit
signing key, and can now accept multiple variables to query at
once, safely formatting the output with a new '-z' option.
Expecting a reroll.
cf. <20260915220228.42819-1-andrewpleeter@gmail.com>
source: <pull.2388.v8.git.git.1789426226860.gitgitgadget@gmail.com>
* tc/push-force-if-includes-fixes (2026-09-17) 3 commits
- push: --force-if-includes should allow fast-forward
- push: fix --force-if-includes non-branch advice
- push: check pushed ref for --force-if-includes
The '--force-if-includes' protection for 'git push' has been updated
to consult the reflog of the local branch being pushed, rather than
incorrectly checking the reflog of a local branch that shares the name
of the remote destination branch. The push advice for detached HEAD
scenarios has also been adjusted to indicate that the remote ref
cannot be verified locally. A regression that caused perfectly valid
fast-forward pushes to be rejected when reflogs were expired has been
fixed.
Needs review.
source: <20260917224351.57171-1-tyler@tylercipriani.com>
* as/push-force-if-includes-no-reflog (2026-09-05) 1 commit
- push: fix --force-if-includes when remote-tracking ref has no reflog
The timestamp used for checking the reflog of a remote-tracking
branch during 'git push --force-if-includes' was left uninitialized
when the reflog was completely empty, which has been corrected.
Waiting for review.
cf. <xmqqjyowz9oq.fsf@gitster.g>
cf. <20260909065639.47316-1-f@lex.la>
source: <20260905171330.34646-1-f@lex.la>
* tb/rerere-lock-grace (2026-09-17) 3 commits
- sequencer: disable auto maintenance in spawned commands
- rebase, cherry-pick, revert: run auto maintenance when done
- config: add git_config_append_parameter()
The sequencer machinery (used by 'git rebase', 'git cherry-pick', and
'git revert') has been updated to defer automatic maintenance tasks
until the end of the operation, preventing nested 'git commit', 'git
merge', and 'exec' commands from triggering GC operations that could
contend for locks or delete open packs while the sequence is in
progress.
Needs review.
source: <pull.2217.v5.git.1789670534.gitgitgadget@gmail.com>
* cc/lazy-fetch-trusted-bit (2026-09-08) 5 commits
- builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo
- promisor-remote: prevent infinite recursion when lazy fetching
- upload-pack: read uploadpack.lazyFetchTrusted
- setup: extract path_allowlist_apply()
- promisor-remote: factor out lazy_fetch_objects()
A new 'uploadpack.lazyFetchTrusted' configuration variable has been
introduced to allow 'upload-pack' to lazily fetch missing objects from
configured promisor remotes when serving trusted repositories.
Waiting for response.
cf. <xmqq7bkvy74h.fsf@gitster.g>
cf. <xmqqqzj3wr24.fsf@gitster.g>
cf. <xmqqmrtrwq0k.fsf@gitster.g>
source: <20260908164129.560396-1-christian.couder@gmail.com>
* cc/early-scan-options (2026-09-02) 6 commits
- fast-import: use early_scan_options() for --allow-unsafe-features
- parse-options: build early scan options from a struct option array
- parse-options: add parse_options_takes_argument()
- rev-parse: fix "--" detection when it is an option value
- bisect: fix "--" detection when a term name is "--"
- parse-options: add early_scan_options()
The process of parsing command-line options in commands that
perform an early scan over their arguments (such as 'git bisect',
'git rev-parse', and 'git fast-import') has been unified using a
new early-scan sub-API, which parses and skips known options taking
separate values to prevent logic bugs.
Waiting for response.
cf. <xmqqpkyviizc.fsf@gitster.g>
source: <20260902161047.476753-1-christian.couder@gmail.com>
* ec/commit-fixup-options (2026-05-26) 2 commits
- commit: allow -c/-C for all kinds of --fixup
- commit: allow -m/-F for all kinds of --fixup
Support for '-m', '-F', '-c', or '-C' options to supply a commit log
message from outside the editor has been added for all 'git commit
--fixup' variations.
Expecting a reroll.
cf. <CA+JQ7M__GOnM9LHt0txry-G2z2CKhdZr0b-rU=Yd_A0gCEwmaQ@mail.gmail.com>
source: <cover.1779792311.git.erik@cervined.in>
* jc/checkout-refactor (2026-08-30) 8 commits
- checkout: move post_checkout_hook() to checkout.c
- checkout: wrap overly long lines
- checkout: restructure switch, restore, and checkout entrypoints
- checkout: extract branch setup and tracking helpers
- checkout: extract option validation and pathspec helpers
- checkout: validate stage and merge option compatibility in checkout_paths()
- checkout: validate new branch name in checkout_branch()
- checkout: pass cb_option explicitly to branch name parsers
The front-end code for 'git checkout', 'git switch', and 'git
restore' has been restructured to cleanly separate their pathspec
and branch handling, eliminating a common bottleneck and paving the
way to libify utility helpers.
Waiting for response.
cf. <xmqqo6el1xz0.fsf@gitster.g>
cf. <xmqqse3x1y20.fsf@gitster.g>
source: <20260830204835.1040408-1-gitster@pobox.com>
* ll/doc-pushcert-if-asked (2026-08-29) 1 commit
- doc: remote-helpers: option pushcert if-asked
The remote helper documentation for the 'pushcert' option has been
updated to mention that it can also take 'if-asked', reflecting the
existing implementation in the code.
Needs review.
source: <20260829183659.29947-1-lorenz.leutgeb@posteo.eu>
* ws/squelch-svn-migrate (2026-08-27) 2 commits
- Makefile: add NO_GIT_SVN knob to skip building/installing git-svn
- git-svn: don't print v1-layout migration noise when there's nothing to migrate
Needs review.
source: <20260827234345.1037130-1-wesleys@opperschaap.net>
* dw/config-read-both-global (2026-08-23) 3 commits
- config: read global scope via config_sequence
- config: let sequence require a successful file
- path: use forward slashes in XDG config on Windows
The git config --global read operations have been updated to respect
both $HOME/.gitconfig and $XDG_CONFIG_HOME/git/config, fixing an
inconsistency where only the former was read when both configuration
files are present.
Expecting a reroll.
cf. <aqIvJhLLcCSnyaL4-delilahwu@linux.microsoft.com>
source: <20260823-fix-config-list-global-home-and-xdg-v2-0-b29cc63f017b@microsoft.com>
* vv/branch-recurse-no-start-ref (2026-08-21) 2 commits
- branch: allow recursion with no tracking name
- branch: do not track a start point with no ref
The --recurse-submodules option in 'git branch' has been fixed to
avoid a crash when the start point is not a reference (e.g., a raw
object ID). The creation path now skips setting up tracking and
properly forwards the absent tracking name to the submodule helper.
Needs review.
source: <20260822-vv-branch-recurse-no-start-ref-v1-0-46dc140acaa8@zitro.id>
* ps/odb-alternates-at-creation (2026-09-10) 9 commits
(merged to 'next' on 2026-09-15 at 4acaa6a8aa)
+ odb/source: remove the ability to write alternates
+ builtin/clone: write alternates via `odb_create_on_disk()`
+ odb/source: support writing alternates when creating the database
+ builtin/clone: move setup of alternates for non-shared local clones
+ builtin/clone: move setup of alternates for shared local clones
+ builtin/clone: refactor handling of "--reference{,-if-able}"
+ builtin/clone: move around `setup_reference()`
+ builtin/clone: defer setup of the object database
+ setup: split up concerns of `init_db()`
+ Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-alternates-at-creation
The setup of alternates has been deferred to object database
creation time during clone, which drops the unused ad-hoc alternate
writing API, simplifying the object database backend interface.
Will cook in 'next'.
cf. <CAOLa=ZRYsJL_0sKnfHD0PJO+5c+BKSMiuN20PeQHKJin82TJDw@mail.gmail.com>
source: <20260910-pks-odb-write-alternates-at-creation-time-v5-0-8d10c4238edc@pks.im>
* as/utimensat-utimes (2026-08-21) 3 commits
- compat/posix: drop legacy <utime.h> header and shims
- treewide: use utimensat(2) instead of legacy utime(3p)
- compat/posix: introduce utimensat(2) wrapper
The codebase has been updated to use the newer utimensat() POSIX
function instead of the obsolescent utime(), allowing
high-precision timestamps while preserving fallback compatibility.
Waiting for response for too long, stalled
cf. <aonIVn-ZQoMKWCAd@fruit.crustytoothpaste.net>
source: <pull.2209.git.1787322203.gitgitgadget@gmail.com>
* kn/receive-report-hook (2026-09-14) 5 commits
(merged to 'next' on 2026-09-15 at aa6cbdb87e)
+ receive-pack: coccinelle fix
+ hook: introduce the receive-report hook
+ receive-pack: move message generation to separate function
+ receive-pack: drop static variables to track report status version
+ doc: add proc-receive hook info in 'git-receive-pack.adoc'
A new hook 'report' is added to 'git receive-pack', which runs after
reference updates and allows the server to filter or modify the
packet-line status report sent back to the client.
Will cook in 'next'.
source: <20260910-758-introduce-hook-v10-0-06f9c506631c@gmail.com>
source: <xmqqwlsn31gq.fsf_-_@gitster.g>
* ap/http-preserve-wwwauth-redirect (2026-08-19) 1 commit
- http: preserve wwwauth_headers across redirects
When an HTTP request triggers a redirect and the target yields an
authentication challenge, the WWW-Authenticate headers received
during the redirect are now explicitly preserved across the
credential URL update, fixing an issue where they were incorrectly
cleared.
Needs review.
source: <20260819-http-preserve-wwwauth-redirect-v2-1-4c61039432b0@nvidia.com>
* kh/format-rev-more-options (2026-08-18) 5 commits
- format-rev: learn --abbrev, --color, and --date
- doc: rev-list-options.adoc: factor out --date alts
- format-rev: factor option variables into a struct
- format-rev: place BUG calls first in callback
- format-rev: use lower case for opts description
The experimental 'git format-rev' has been taught a few more
formatting options.
Needs review.
source: <V2_CV_format-rev_three_more_opts.bd3@msgid.xyz>
* gg/http-ssl-verify-status (2026-09-15) 1 commit
- http: add http.sslVerifyStatus to check stapled OCSP responses
The HTTP transport has been taught to check the revocation status of
the server certificate using the stapled OCSP response during the
TLS handshake via a new 'http.sslVerifyStatus' configuration
variable.
Will merge to 'next'?
cf. <xmqqv785uha7.fsf@gitster.g>
source: <20260915162348.97792-1-ggordon@gitlab.com>
* ty/repo-config-cleanups (2026-08-07) 3 commits
- environment: remove inaccurate repo_config_values comments
- environment: clarify repository config getter documentation
- environment: drop redundant NULL checks in config getters
Repository configuration getters in 'environment.c' have been
simplified by removing redundant NULL checks. The documentation for
these getters in 'environment.h' has been clarified, and inaccurate
section comments inside 'struct repo_config_values' have been removed.
Waiting for response for too long, stalled
cf. <aqOeHlPWer60LcoO@pks.im>
source: <20260807085932.3958759-1-cat@malon.dev>
* dk/use-nsec-runtime (2026-09-11) 3 commits
(merged to 'next' on 2026-09-15 at 67ef6d82ef)
+ core: convert build-time USE_NSEC into runtime core.useNanosec
+ environment: align repo_config_values_init with struct declaration
+ meson: expose knob for xmlto relative links in manuals
The build-time knob 'USE_NSEC' for nanosecond stat precision has been
converted to a runtime configuration 'core.useNanosec', allowing
distributions to bundle one binary that adapts to filesystem
capabilities dynamically.
Will cook in 'next'.
cf. <apVJCt4prIi2GgXp@pks.im>
source: <cover.1789129924.git.ben.knoble@gmail.com>
* bc/restrict-hex-to-lowercase (2026-09-07) 7 commits
- hex: allow only lowercase object IDs in breaking changes mode
- t5324: adjust tests for corrupt commit-graph
- object-name: use hexval
- hex: label usages of hex parsing for object IDs
- hex: make hex_to_bytes accept kind of hex to use
- hex: allow specifying hex type with hex2chr
- hex: add functionality for lowercase-only hex
The parser for hex object names has been updated to reject uppercase
hexadecimal characters when running in the breaking changes mode, in
preparation for Git 3.0.
Needs review.
source: <20260907195941.1024289-1-sandals@crustytoothpaste.net>
* kj/repo-info-more-path-keys (2026-09-11) 7 commits
- repo: add path.cdup
- repo: add path.git-prefix
- repo: add path.grafts with absolute and relative suffixes
- repo: add path.index with absolute and relative suffixes
- repo: add path.hooks with absolute and relative suffixes
- repo: add path.superproject-root with absolute and relative suffixes
- repo: add path.toplevel with absolute and relative suffix formatting
The 'git repo info' command has been taught more keys to output
paths of various repository components (such as the working tree
root, superproject working tree, object database, etc.), supporting
both absolute and relative path formats.
Waiting for response.
cf. <xmqqse3fbudk.fsf@gitster.g>
cf. <xmqqcxujbser.fsf@gitster.g>
source: <20260911144519.1011780-1-jayatheerthkulkarni2005@gmail.com>
* tc/last-modified-bloom (2026-09-01) 6 commits
- last-modified: keep per-path Bloom filters for wildcard pathspecs
- last-modified: check pathspec against Bloom filter first
- revision: add Bloom check that includes parent directories
- bloom: add helper to check if any key in a vector is present
- revision: expose check for paths maybe changed in Bloom filter
- revision: move bloom keyvec precondition into function
The 'git last-modified' command has been optimized by using Bloom
filters. It now reuses revision walk filtering logic from 'git log'
to pre-filter commits, and maintains per-path Bloom filters even when
wildcard pathspecs are used.
Waiting for response.
cf. <aqJWihcFmX7tPio5@pks.im>
cf. <aqJWX0INerT8F687@pks.im>
source: <20260901-toon-speed-up-last-modified-v4-0-a09949800404@iotcl.com>
* ds/trace2-tolerate-failed-timestamp (2026-08-31) 7 commits
- trace2: remove use of xcalloc()
- trace2: remove use of ALLOC_GROW()
- trace2: remove use of xstrfmt()
- trace2: remove use of ALLOC_ARRAY()
- trace2: remove use of xstrdup()
- trace2: tolerate failed timestamp formatting
- banned-die: create header for banning of functions
Functions like `xstrfmt()` and `xcalloc()` have been banned from use
in the trace2 API codebase to prevent calls to `die()` which lead to
unwanted process exits and recursion when memory allocation fails.
Needs review.
source: <pull.2178.v3.git.1788197143.gitgitgadget@gmail.com>
* pz/fetch-submodule-errors-config (2026-07-16) 2 commits
- fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal
- submodule: fix premature failure in recursive submodule fetch
The 'git fetch' command can now configure how submodule fetch errors
are handled via 'fetch.submoduleErrors' and '--submodule-errors',
making them non-fatal. A premature failure during recursive submodule
fetches has been fixed by deferring the error until the OID-based
retry phase fails.
Needs review.
source: <20260716140956.1023740-1-paulius.zaleckas@gmail.com>
* fz/rebase-autosquash-empty (2026-08-27) 1 commit
- sequencer: honor --empty when a fixup!/squash! empties its target
A commit that is emptied by melding a 'fixup!' or 'squash!' commit
during 'git rebase --autosquash' is now handled according to the
'--empty' option, allowing it to be dropped, kept, or to halt the
rebase.
Waiting for response.
cf. <511300fe-112d-4f20-bd3f-e401e68c4a27@gmail.com>
source: <20260827-fz-autosquash-empty-v4-1-f98ffd575780@gmail.com>
* ij/subtree-reject-v2-config (2026-07-06) 2 commits
- git-subtree: Bail out if we find output from Rust rewrite (test)
- git-subtree: Bail out if we find output from Rust rewrite
The shell script implementation of 'git subtree' has been updated to
check for the presence of the configuration file of the new Rust
implementation, preventing users from accidentally running the old
script on repositories already managed by the new tool.
Expecting a reroll.
cf. <27219.20156.438730.881821@chiark.greenend.org.uk>
source: <20260706115816.20267-1-ijackson@chiark.greenend.org.uk>
* mm/line-log-limited-ops (2026-09-02) 7 commits
- diffcore-pickaxe: limit -G to the -L tracked range
- diff: support --check with -L line ranges
- diff: support stat formats with -L
- diff: extract a line-range diff helper for reuse
- diff: emit -L hunk headers via xdiff's formatter
- diff: simplify the line-range filter by classifying removals immediately
- diff: rename line-range filter struct and clarify fields
(this branch is used by mm/diff-process-hunks.)
The 'git log -L<range>:<path>' command has been taught to limit
various 'diff' operations, such as '--stat', '--check', and '-G', to
the specified range and path.
Needs review.
source: <pull.2152.v3.git.1788411919.gitgitgadget@gmail.com>
* hn/history-squash (2026-09-08) 8 commits
(merged to 'next' on 2026-09-15 at 28dd773b8b)
+ history: support editing squashed commit messages
+ history: create squashed commits without editing
+ history: protect branches when squashing a range
+ history: validate squash revision ranges
+ history: add skeleton for squash subcommand
+ sequencer: share the squash message marker helpers and flags
+ history: give commit_tree_ext a message template
+ history: extract helper for a commit's parent tree
The experimental 'git history' command has been taught a new 'squash'
subcommand to fold a range of commits into a single commit, with any
descendants replayed on top.
Will cook in 'next'.
cf. <xmqqik4fv4v1.fsf@gitster.g>
source: <pull.2337.v15.git.git.1788900119.gitgitgadget@gmail.com>
* tb/midx-incremental-custom-base (2026-06-12) 3 commits
- midx-write: include packs above custom incremental base
- midx: pass custom '--base' through incremental writes
- t5334: expose shared `nth_line()` helper
The 'git multi-pack-index write --incremental' command has been
corrected to properly honor the '--base' option. Previously, the
custom base was ignored by the normal write path; packs from layers
above the selected base were incorrectly skipped by the pack exclusion
logic, and reachability closure for bitmaps was broken.
Expecting a reroll.
cf. <an4uIQA09rDCwwBp@com-79390>
cf. <apUbQ4S-zJGtBeu2@pks.im>
source: <cover.1781294771.git.me@ttaylorr.com>
* mm/diff-process-hunks (2026-08-13) 11 commits
- fixup! diff: consult oid-only hunk providers via diff.<driver>.process
- diff: consult oid-only hunk providers via diff.<driver>.process
- userdiff: add diff.<driver>.process config
- sub-process: add a gentle status read
- sub-process: separate process lifecycle from hashmap management
- blame: read precomputed hunks
- diff: read precomputed hunks for stat output
- diff: record precomputed hunks during stat output
- diff-hunks: add the store format, library, and command
- diff: introduce a hunk provider interface
- gitattributes: document how external diff drivers relate to diff features
- Merge branch 'mm/line-log-limited-ops' into mm/diff-process-hunks
(this branch uses mm/line-log-limited-ops.)
A new 'diff.<driver>.process' configuration has been introduced to
allow a long-running external process to act as a hunk provider,
enabling external tools to control which lines Git considers changed
while leaving all output formatting (word diff, color, blame, etc.) to
Git's standard pipeline.
Expecting a reroll.
cf. <CAC2Qwm+kzT_3_GKrpay=JLGYsxS10oWCg2MJPHrCVogFHA0OdA@mail.gmail.com>
source: <20260801174156.2998808-1-mmontalbo@gmail.com>
* kh/format-patch-range-diff-notes (2026-08-24) 3 commits
. format-patch: learn --[no-]range-diff-notes
. revision.h: rename struct member to reflect notes role
. format-patch: simplify get_notes_arg parameters
The 'format-patch' command has been updated with options to
configure notes specifically for range-diff output, allowing them to
differ from the notes displayed on the patches themselves.
Expecting a reroll.
cf. <8f0a076b-4822-44e2-a842-cc1e39ae1c1d@app.fastmail.com>
source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
^ permalink raw reply [flat|nested] 21+ messages in thread* kh/format-patch-range-diff-notes
2026-09-22 0:11 What's cooking in git.git (Sep 2026, #08) Junio C Hamano
@ 2026-09-22 8:11 ` Kristoffer Haugsbakk
2026-09-22 13:25 ` Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Johannes Schindelin
1 sibling, 0 replies; 21+ messages in thread
From: Kristoffer Haugsbakk @ 2026-09-22 8:11 UTC (permalink / raw)
To: Junio C Hamano, git
On Tue, Sep 22, 2026, at 02:11, Junio C Hamano wrote:
> * kh/format-patch-range-diff-notes (2026-08-24) 3 commits
> . format-patch: learn --[no-]range-diff-notes
> . revision.h: rename struct member to reflect notes role
> . format-patch: simplify get_notes_arg parameters
>
> The 'format-patch' command has been updated with options to
> configure notes specifically for range-diff output, allowing them to
> differ from the notes displayed on the patches themselves.
>
> Expecting a reroll.
> cf. <8f0a076b-4822-44e2-a842-cc1e39ae1c1d@app.fastmail.com>
> source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
I’ll comment since it’s almost been a month. It’s a straightforward
reroll but I haven’t been able to do the about hour’s worth of work.
I should get some time at the latest on the weekend.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 0:11 What's cooking in git.git (Sep 2026, #08) Junio C Hamano
2026-09-22 8:11 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
@ 2026-09-22 13:25 ` Johannes Schindelin
2026-09-22 13:49 ` Junio C Hamano
1 sibling, 1 reply; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-22 13:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Mon, 21 Sep 2026, Junio C Hamano wrote:
> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
> the final Git 2.56 release, but otherwise I do not expect any new
> feature topics to be ready before the final, so most of the
> in-flight topics will stay cooking in 'next' until then. As
> discussed at the Git Contributors' Summit, the version after the
> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
> year.
Would you say that the following is an accurate characterization of the
timeline, so that people who need to plan dependent projects can rely on
it?
The participants of the Git Contributor Summit agreed on a certain release
shape, rather than timing: release v2.99.1 and v3.0 simultaneously,
differing only in the breaking-change defaults. The timeline discussed was
v2.56 in September, v2.98 in December, then v2.99/v3.0 around March 2027;
April also came up. Dropping v2.57 in favor of v2.98 was an explicit
decision. This would make v3.0 principally a deliberate compatibility
transition, rather than a separate batch of features.
Rust was treated as mandatory for v3.0, and the explicit check for
objections drew none from anyone in the room. Compared with the
contentious portability discussion on the Git mailing list, that is a
notable signal. It does not establish that the portability problems
themselves are solved.
One of Git v3.0's bigger-impact challenges is SHA-256 interoperability,
which is purportedly done, but not on the Git mailing list yet, and there
was affirmation that it will handle historical tags too. While GitLab
already has support for SHA-256, GitHub has it only in private preview
with general availablility likely before the end of the year. JGit does
_not_ have SHA-256 support, and no participant knew of anyone funding it.
The ecosystem transition therefore remains uneven.
Is this a fair summary of the "Git v3.0" breakout session at the Git
Contributor Summit, from your point of view?
Ciao,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 13:25 ` Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Johannes Schindelin
@ 2026-09-22 13:49 ` Junio C Hamano
2026-09-22 17:06 ` Johannes Schindelin
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
0 siblings, 2 replies; 21+ messages in thread
From: Junio C Hamano @ 2026-09-22 13:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>
>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>> the final Git 2.56 release, but otherwise I do not expect any new
>> feature topics to be ready before the final, so most of the
>> in-flight topics will stay cooking in 'next' until then. As
>> discussed at the Git Contributors' Summit, the version after the
>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>> year.
>
> Would you say that the following is an accurate characterization of the
> timeline, so that people who need to plan dependent projects can rely on
> it?
My outline was deliberately limited up to end of this year as I am
hesitant to say beyond that point before the meeting notes are made
public. I am not sure who will be releasing it to the public and
when, though with the open nature of this community I believe it
will happen soon. I do not recall anything controversial in the 3.0
section of the meeting notes.
> Rust was treated as mandatory for v3.0, and the explicit check for
> objections drew none from anyone in the room. Compared with the
> contentious portability discussion on the Git mailing list, that is a
> notable signal. It does not establish that the portability problems
> themselves are solved.
It signals that the room was smaller than the list. Or enough time
passed since we discussed some minority platforms having trouble
with Rust the last time to change the situation. Or little bit of
both ;-)
Thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 13:49 ` Junio C Hamano
@ 2026-09-22 17:06 ` Johannes Schindelin
2026-09-24 3:56 ` Junio C Hamano
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
1 sibling, 1 reply; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-22 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Tue, 22 Sep 2026, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 21 Sep 2026, Junio C Hamano wrote:
> >
> >> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
> >> the final Git 2.56 release, but otherwise I do not expect any new
> >> feature topics to be ready before the final, so most of the
> >> in-flight topics will stay cooking in 'next' until then. As
> >> discussed at the Git Contributors' Summit, the version after the
> >> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
> >> year.
> >
> > Would you say that the following is an accurate characterization of the
> > timeline, so that people who need to plan dependent projects can rely on
> > it?
>
> My outline was deliberately limited up to end of this year as I am
> hesitant to say beyond that point before the meeting notes are made
> public. I am not sure who will be releasing it to the public and
> when, though with the open nature of this community I believe it
> will happen soon. I do not recall anything controversial in the 3.0
> section of the meeting notes.
Fair enough: I did ask you to confirm my summit summary. Let me separate
that from what I need for planning: a proposal from you as release
maintainer can be discussed on the list on its own merits, without waiting
for publication of the meeting record or claiming summit consensus.
Could you use the next What's cooking to outline your working release
plan: whether paired 2.99.1/3.0 releases in March or April 2027 would be
your proposed target, what conditions could move it, and when we should
review that target?
If you cannot yet choose a target, could that update identify what needs
resolving and when you expect to revisit the choice?
Your assessment would give dependent projects a common baseline to
coordinate around. A provisional planning assumption would be useful; it
need not be a guarantee.
Thanks,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 17:06 ` Johannes Schindelin
@ 2026-09-24 3:56 ` Junio C Hamano
2026-09-24 4:30 ` Junio C Hamano
0 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2026-09-24 3:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Fair enough: I did ask you to confirm my summit summary. Let me separate
> that from what I need for planning: a proposal from you as release
> maintainer can be discussed on the list on its own merits, without waiting
> for publication of the meeting record or claiming summit consensus.
As I wrote, after the current cycle ends at the end of this month, a
10-12 week cycle including the end-of-year slowness would mean the
next cycle 2.98 will end at the end of this year. Expolation from
there, 2.99 will be March 2027.
The consensus in the room was that we want to use 2.99 as a signal
that something big is coming, so between 2.99 and 3.0 needs to be
some lead time for "advertisement". This lead time between 2.99 and
3.0 does not have to be the usual 8-to-12-weeks full release cycle.
I do not think there was a firm agreement on the date for 2.99.1 and
3.0. Potential factors mentioned in the room included that we may
want to match the LTS release schedule of major distros. My
preference would be to give a month after 2.99 to apply only
accumulated bugfixes and nothing else and tag it as 2.99.1, which
means 2.99.1 would be April 2027.
The contents of 3.0 should be identical to 2.99.1 except for the
breaking changes are enabled in 3.0 while they are disabled in
2.99.1. Volunteers can run 2.99.X series indefinitely to help LTS
distributions.
At the release engineering level, I am very tempted to keep the
WITH_BREAKING_CHANGES Makefile knob in 3.0 release in order to keep
the differences between 2.99.1 and 3.0 to absolute minimum, and then
remove the "dead code" that is used when WITH_BREAKING_CHANGES is
not enabled from 3.X at our leasure.
So the above is what I have in mind, shaped mostly around the
concensus at Contributor's summit (or at least how I understand what
the concensus was), with my preference filling in what was not
firmly decided in the room.
Good enough?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-24 3:56 ` Junio C Hamano
@ 2026-09-24 4:30 ` Junio C Hamano
2026-09-24 12:29 ` Johannes Schindelin
2026-09-24 18:08 ` Ramsay Jones
0 siblings, 2 replies; 21+ messages in thread
From: Junio C Hamano @ 2026-09-24 4:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> As I wrote, after the current cycle ends at the end of this month, a
> ...
It was so full of typoes and grammos because I didn't pass it thru
spell checker as usual. Sorry about that. Here is a replacement.
As I wrote, after the current cycle ends at the end of this month, a
10-to-12-week cycle including the end-of-year slowness would mean the
next cycle, 2.98, will end at the end of this year. Extrapolating
from there, 2.99 will be March 2027.
The consensus in the room was that we want to use 2.99 as a signal
that something big is coming, so there needs to be some lead time
between 2.99 and 3.0 for "advertisement". This lead time between
2.99 and 3.0 does not have to be the usual 8-to-12-week full release
cycle.
I do not think there was a firm agreement on the date for 2.99.1 and
3.0. Potential factors mentioned in the room included that we may
want to match the LTS release schedule of major distributions. My
preference would be to give a month after 2.99 to apply only
accumulated bugfixes and nothing else, and tag it as 2.99.1, which
means 2.99.1 would be April 2027.
The contents of 3.0 should be identical to 2.99.1 except that
breaking changes are enabled in 3.0 while they are disabled in
2.99.1. Volunteers can run the 2.99.x series indefinitely to help
LTS distributions.
At the release engineering level, I am very tempted to keep the
WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to
keep the differences between 2.99.1 and 3.0 to an absolute minimum,
and then remove the "dead code" that is used when
WITH_BREAKING_CHANGES is not enabled from the 3.x series at our
leisure.
So the above is what I have in mind, shaped mostly around the
consensus at the Contributors' Summit (or at least how I understand
what the consensus was), with my preference filling in what was not
firmly decided in the room.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-24 4:30 ` Junio C Hamano
@ 2026-09-24 12:29 ` Johannes Schindelin
2026-09-24 17:00 ` Junio C Hamano
2026-09-24 18:08 ` Ramsay Jones
1 sibling, 1 reply; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-24 12:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 23 Sep 2026, Junio C Hamano wrote:
> As I wrote, after the current cycle ends at the end of this month, a
> 10-to-12-week cycle including the end-of-year slowness would mean the
> next cycle, 2.98, will end at the end of this year. Extrapolating
> from there, 2.99 will be March 2027.
>
> The consensus in the room was that we want to use 2.99 as a signal
> that something big is coming, so there needs to be some lead time
> between 2.99 and 3.0 for "advertisement". This lead time between
> 2.99 and 3.0 does not have to be the usual 8-to-12-week full release
> cycle.
>
> I do not think there was a firm agreement on the date for 2.99.1 and
> 3.0. Potential factors mentioned in the room included that we may
> want to match the LTS release schedule of major distributions. My
> preference would be to give a month after 2.99 to apply only
> accumulated bugfixes and nothing else, and tag it as 2.99.1, which
> means 2.99.1 would be April 2027.
>
> The contents of 3.0 should be identical to 2.99.1 except that
> breaking changes are enabled in 3.0 while they are disabled in
> 2.99.1. Volunteers can run the 2.99.x series indefinitely to help
> LTS distributions.
>
> At the release engineering level, I am very tempted to keep the
> WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to
> keep the differences between 2.99.1 and 3.0 to an absolute minimum,
> and then remove the "dead code" that is used when
> WITH_BREAKING_CHANGES is not enabled from the 3.x series at our
> leisure.
>
> So the above is what I have in mind, shaped mostly around the
> consensus at the Contributors' Summit (or at least how I understand
> what the consensus was), with my preference filling in what was not
> firmly decided in the room.
Thank you so much! This will make it much easier for me to plan out the
Git for Windows roadmap, such as switching to Rust-based builds and
integrating Git Credential Manager v3.0.
Ciao,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-24 12:29 ` Johannes Schindelin
@ 2026-09-24 17:00 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2026-09-24 17:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> So the above is what I have in mind, shaped mostly around the
>> consensus at the Contributors' Summit (or at least how I understand
>> what the consensus was), with my preference filling in what was not
>> firmly decided in the room.
>
> Thank you so much! This will make it much easier for me to plan out the
> Git for Windows roadmap, such as switching to Rust-based builds and
> integrating Git Credential Manager v3.0.
Note that I consider it risky to treat the timeline as already set
in stone.
In particular, if we find that 2.99 needs a longer stabilization
effort, we may need to slip 2.99.1 by a month or follow it with
2.99.2 or even 2.99.3, and 3.0 may have to coincide with one of
these later maintenance releases. Anything beyond the end of this
year is in "we do not yet know and we will play it by ear when the
time comes" territory.
Thanks.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-24 4:30 ` Junio C Hamano
2026-09-24 12:29 ` Johannes Schindelin
@ 2026-09-24 18:08 ` Ramsay Jones
1 sibling, 0 replies; 21+ messages in thread
From: Ramsay Jones @ 2026-09-24 18:08 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git, Adam Dinwoodie
On 24/09/2026 5:30 am, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
[snip]
> As I wrote, after the current cycle ends at the end of this month, a
> 10-to-12-week cycle including the end-of-year slowness would mean the
> next cycle, 2.98, will end at the end of this year. Extrapolating
> from there, 2.99 will be March 2027.
>
> The consensus in the room was that we want to use 2.99 as a signal
> that something big is coming, so there needs to be some lead time
> between 2.99 and 3.0 for "advertisement". This lead time between
> 2.99 and 3.0 does not have to be the usual 8-to-12-week full release
> cycle.
>
> I do not think there was a firm agreement on the date for 2.99.1 and
> 3.0. Potential factors mentioned in the room included that we may
> want to match the LTS release schedule of major distributions. My
> preference would be to give a month after 2.99 to apply only
> accumulated bugfixes and nothing else, and tag it as 2.99.1, which
> means 2.99.1 would be April 2027.
>
> The contents of 3.0 should be identical to 2.99.1 except that
> breaking changes are enabled in 3.0 while they are disabled in
> 2.99.1. Volunteers can run the 2.99.x series indefinitely to help
> LTS distributions.
>
> At the release engineering level, I am very tempted to keep the
> WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to
> keep the differences between 2.99.1 and 3.0 to an absolute minimum,
> and then remove the "dead code" that is used when
> WITH_BREAKING_CHANGES is not enabled from the 3.x series at our
> leisure.
>
> So the above is what I have in mind, shaped mostly around the
> consensus at the Contributors' Summit (or at least how I understand
> what the consensus was), with my preference filling in what was not
> firmly decided in the room.
Back in January, on the cygwin-announce list[1], an experimental rust package
was announced. This package was marked experimental and unmaintained in the
cygwin setup program. I was hoping for a more 'official' package to emerge
before trying it out on git. (the package was version 1.91.0 of rust built
from a source tarball). However, there has been no sign of a formal supported
(test or production) package since then (there is still time, of course). ;)
Anyway, this thread prompted me to try the experimental package:
$ vim config.mak # comment out NO_RUST
$ cat config.mak
DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS=--timer -j8
#NO_RUST=1
NO_DC_SHA1_SUBMODULE=NoThanks
DEVELOPER=1
$
Having fetched today, the 'master' branch @0f8e75abeb is v2.56.0-rc2 with
the branch 'en/no-amend-during-conflicts' reverted.
$ make >out1 2>&1
$ ./git version
git version 2.56.0.rc2.1.g0f8e75abeb
$ git describe
v2.56.0-rc2-1-g0f8e75abeb
$ diff out out1
1c1
< GIT_VERSION=2.56.0.rc2
---
> GIT_VERSION=2.56.0.rc2.1.g0f8e75abeb
277d276
< CC varint.o
308a308
> CARGO target/release/libgitcore.a
$
The 'out' file is yesterdays build of v2.56.0-rc2. (Similarly, the 'sp-out',
'sc' and 'hcout' files record output for v2.56.0-rc2).
$ make sparse >sp-out1 2>&1
$ diff sp-out sp-out1
268d267
< SP varint.c
$
$ ./static-check.pl >sc1
$ diff sc sc1
$
$ make -k hdr-check >hcout1 2>&1
$ diff hcout hcout1
$
$ . ../git-test-setup
$ env | grep TEST
TEST_NO_MALLOC_CHECK=yes
GIT_TEST_CHAIN_LINT=0
$ make test >test-out-2-56-rc2-1 2>&1
$ tail -n 13 test-out-2-56-rc2-1
Test Summary Report
-------------------
unit-tests/bin/unit-tests.exe (Wstat: 256 (exited 1) Tests: 261 Failed: 1)
Failed test: 254
Non-zero exit status: 1
t9904-url-parse.sh (Wstat: 256 (exited 1) Tests: 53 Failed: 4)
Failed tests: 39, 42-43, 47
Non-zero exit status: 1
Files=1060, Tests=33592, 3519 wallclock secs (42.61 usr 141.30 sys + 9056.74 cusr 12680.95 csys = 21921.60 CPU)
Result: FAIL
make[1]: *** [Makefile:82: prove] Error 1
make[1]: Leaving directory '/home/ramsay/git/t'
make: *** [Makefile:3424: test] Error 2
$
Despite the failure, this shows exactly the same failures as v2.56.0-rc2.
So, this doesn't stress the rust compiler very much, but I guess it is
slightly encouraging! I suppose Brian has plenty of rust code in a branch
somewhere that could be tested ...
Unfortunately, I am just about (in a few hours) to go into hospital for a
surgical procedure, so I will be AWOL for some time yet, ...
ATB,
Ramsay Jones
[1] https://sourceware.org/pipermail/cygwin-announce/2026-January/012823.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 13:49 ` Junio C Hamano
2026-09-22 17:06 ` Johannes Schindelin
@ 2026-09-22 18:44 ` Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
` (3 more replies)
1 sibling, 4 replies; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-22 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Tue, 22 Sep 2026, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 21 Sep 2026, Junio C Hamano wrote:
> >
> >> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
> >> the final Git 2.56 release, but otherwise I do not expect any new
> >> feature topics to be ready before the final, so most of the
> >> in-flight topics will stay cooking in 'next' until then. As
> >> discussed at the Git Contributors' Summit, the version after the
> >> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
> >> year.
> >
> > Would you say that the following is an accurate characterization of the
> > timeline, so that people who need to plan dependent projects can rely on
> > it?
>
> My outline was deliberately limited up to end of this year as I am
> hesitant to say beyond that point before the meeting notes are made
> public.
I originally wrote this summary of the Git Contributor Summit only for my
own records, but since you hinted at wanting some meeting notes, figured
it might be interesting to other people, too. So here goes my distillation
of the breakout-sessions from this year's Contributors' Summit. Many of
these ideas still need discussion on the list; proposals below are not
project-wide decisions.
Security mailing list and process
The security list is seeing a large influx of outside reports, apparently
often AI-assisted or generated. Duplicates and reports outside Git's
security model consume triage time, while some patches have waited for
months. Waiting for an empty queue is not a workable release criterion: we
need to release the fixes we have, rather than hold them indefinitely
while more reports arrive. No fixed release cadence or guaranteed response
time was settled.
Documenting Git's security model would save repeated explanations of what
does and does not constitute a vulnerability. (Personal note, not
discussed at the Summit: Stolee had tried to start a conversation about
Git's security boundary a long time ago, but nobody replied. Maybe the AI
onslaught will provide enough motivation to get that discussion going.)
Moving non-security bugs to the public list more readily was also
encouraged. A timeout after which public discussion would be presumed OK
was proposed, but not agreed.
More company staffing would help, without turning this into an obligation
for volunteers. Paying for dedicated help was discussed, with onboarding
costs a concern. Using AI for triage or fixes raises confidentiality and
DCO questions of its own. (Personal note: There seemed to be some
sentiment in the room that contradicted the earlier agreed-on finding on
the mailing list that using AI for triaging and for investigating wasn't a
copyright concern and should therefore be considered permissible.)
The release bottleneck is not really tag automation. Merging and
backporting fixes, preparing advisories, and handling CVEs take work, and
too much of that knowledge lives in people's heads. Peff volunteered to
start a public discussion of the process and dig up existing resources.
(Personal note: I have done that merging, backporting, etc plenty of
times, and I don't think that it is the bottleneck, and I was rather
surprised to hear that it is complicated. Sure, there are the expected
merge conflicts when merging `maint-*` branches, and running -- and
fixing! -- CI on all of the tags in a private repository should go without
saying, but that's all craft of the trade. Rather, the indecision and lack
of engagement on the git-security mailing list is what I see as the
blocker. I'd happily volunteer to juggle those branch thickets if that was
truly the make-or-break issue here.)
Microsoft's release process reportedly needs about seven weeks. There were
no objections in the room to proceeding without waiting for that schedule.
(Personal note: That release process was misrepresented, which is
surprising, as I coordinated two or three Git for Windows security bugfix
releases _on the git-security list_ since the most recent Git security
bugfix release, it's always the same thing: release on a second Tuesday of
the month, three weeks before that the patches need to have settled,
everybody goes home with a dependable timeline. It's not really that big
of a deal. Testing patches, constructive feedback, these are the things
that are missing and therefore blocking the process. I sensed a lot of
finger-pointing in this discussion. I mean, I don't blame anybody for
avoiding security work: it is stressful and intense. The responsibility
for getting things wrong is enormous. I know that because I've done my
share of that, probably more than most in the Git project, and I will do
even more in the future. But when I don't have the time, or the energy, I
am aware that I, myself, am the bottleneck; I don't need to blame others.)
Git v3.0
The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
December, then v2.99 and v3.0 next spring. The jump in version numbers is
intended to signal the approaching breaking changes. March and April were
both mentioned; the precise timing is not settled.
There was agreement on releasing v2.99.1 and v3.0 together, differing only
in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
separate from another round of feature development. Nobody in the room
objected to Rust becoming mandatory in v3.0. (Personal note: probably
because Randall wasn't there, to say that NonStop support would be a
blocker and that Git please wait.) A v2.x LTS remains an open question,
with Gentoo mentioned as an interested party. (Personal note: I am still
advocating for an in-tree Long Term Support branch, and since Junio
indicated that he's less than eager to take care of that, I would love for
Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
said he'd do it if asked, and I trust his judgement, so I'd ask.)
SHA-256 support across the ecosystem had been a blocker. GitHub reported
experimental support, with general availability expected around November.
GitLab already had public, non-experimental support, and libgit2 supports
it, too. JGit remains a gap; Google was not planning to fund that work.
The SHA-1/SHA-256 interoperability work, including historical tags, was
reported to be implemented but not yet sent to the list. (Personal note: I
think that the room seriously "mis-underestimated" the real-world impact
of this. The code is not even on the Git mailing list, and the
ramifications of not having a robust plan how to deal with partial clones
or submodules or even signed tags strikes me as a dealbreaker. I would not
be surprised if the decision to enforce SHA-256 as default would have to
be revisited before v3.0, and possibly overturned.)
Documentation
Julia's work highlights the gap between documentation written by people
who know Git inside out and users who do not yet know what objects, the
index, or upstream mean. We need approachable learning material as well as
reference documentation. Both need work; keeping manpages concise does not
mean they cannot have better explanations and examples. (Personal note: I
am beyond excited that Julia, whose work I have always admired, got
interested in improving Git's documentation, which is in dear need of
being improved, mainly because it does not cater to the majority of Git
users out there who are unlikely to wander onto the Git mailing list,
ever. I just hope that old-timers who really do not need the documentation
nor understand the need of those who do need it show enough appreciation
for the fresh views and for Julia's understanding of the target audience.)
Discoverability matters, too. The website (https://git-scm.com/) needs
clearer entry points for learning Git, and existing guides are harder to
find than manpages. Missing subsection links are another improvement we
could make incrementally. (Personal note: Judging by the history of that
site, I do wonder whether the core Git contributors are interested in
helping this effort at all. For example, there are a growing number of PRs
suggesting to add new UIs to the growing list, but I gave up reviewing
them because I was the only one doing so.)
There was support for replacing outdated material and for merging useful
improvements, then iterating, rather than trying to perfect everything
before it lands. Bringing user feedback to the list without flooding it
remains a challenge.
The current funding covers only 100 hours split between two people.
Additional project and company funding was encouraged; brian, Emily, and
Mark offered to explore company support. (Personal note: I had tried, back
when GitHub still funded my team, to start something like that, without
any success. To the contrary, even Git for Windows and Git Credential
Manager got defunded.)
On the tooling side, using only Asciidoctor instead of maintaining both
AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
change. Distribution support and rendering differences need checking, with
doc-diff suggested for comparing the outputs. Patrick filed an issue
during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
maintained by Asciidoctor, and I am aware already of one change that was
made to the spec without adapting AsciiDoc accordingly. So the entire
discussion might be quite moot already.)
Other ideas included richer diagrams for HTML while retaining text
versions for manpages, and privacy-respecting traffic measurements to help
prioritize documentation work. No diagram format was chosen, and caching
and AI scraping complicate getting useful traffic data. Mermaid was
proposed, and even GraphViz. (Personal note: I added support for Mermaid
diagrams to https://git-scm.com/, but it turned out to be too limited, so
I added GraphViz support. The support code for this is a bit of a beast,
having a wasm version of GraphViz for development, pre-rendering the
diagrams as SVG and as PDF during deployment of the site; it was quite a
bit of fun to implement all that.)
Outreachy sponsoring
The goal is to support three interns in the round starting in early
December, at $10,000 each. The corporate sponsorship previously provided
by GitLab and GitHub has dried up, leaving Git itself to pay. There are
company contacts to follow up with; Emily offered to ask Google's OSPO,
without high expectations. No new sponsorship commitments were made.
(Personal note: I don't think that these internships provide enough
publicity to give companies much of an incentive to fund this. Which I
find a bit of a shame, Outreachy in particular does a lot of important,
good work, and if I wasn't so constantly overworked, I would want to
mentor again; I always found it rewarding, even if I hold myself to a
quite high bar which is quite draining.)
A related point for Git Merge 2027: announcing the location early would
help Outreachy and GSoC interns plan attendance. No location was selected.
Pluggable object database
Patrick's pluggable object database is working, but it is not complete:
commit-graph and multi-pack-index integration are still outstanding, and a
repository extension is planned. (Personal note: It might be interesting
to see whether implementing a storage backend is easier in core Git or in
another Git-compatible implementation. JGit should be a natural target,
having originated within BigTable-sized constraints, i.e. a different
storage system, but funding seems to have dried up, there's not even
SHA-256 support, so JGit might not be as hackable as it once was.)
Content-defined chunking prompted an important distinction between
changing how objects are stored and changing the logical object model.
Starting at the storage layer would let us preserve existing blob OIDs
rather than require ecosystem-wide changes. A new pack/index format could
provide another representation of the same object, much as deltas do
today. No particular representation was agreed. (Personal note: It is
curious to me why nobody tought about inventing a "meta blob", i.e. an
object much like a tree object, except that it stitches together a larger
blob. This would allow for the content-defined chunking that `rsync`
already championed, way before Git was born! It would have allowed a Git
native large file support worth writing home about, and could have
replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
not have had to be invented, and it would have allowed game development to
move to Git. I can only imagine that the time it would cost to get even
the first patches of this into core Git would be seen as prohibitive by
any company who may have considered the effort.)
There is also an API question: does a backend seeing only object content
have enough context to make good storage and delta choices, or should it
receive richer information? More searchable tree storage and a Git "commit
cloud" were other possibilities raised, not committed plans. (Personal
note: At a previous GitMerge, Facebook presented their work, see e.g.
https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
which includes separating actual storage from transport. That is, already
at push time, derived metadata is computed in async jobs which provide
several potential deltas ready-to-go when a client clones or fetches. They
reported clones with regular Git clients that are twice as fast, just
because the server doesn't need to spend much compute on the data it
sends. So there is a lot to be learned out there already.)
AI
The current SubmittingPatches policy is rooted in DCO certification and
advice from SFC lawyers. The unresolved question is whether, and to what
extent, contributors can certify AI-generated code. There was substantial
disagreement about acceptable use, provenance and legal risks, community
trust, review burden, and whether the current caution excludes useful
tools. No policy change was agreed. (Personal note: You'd think that the
opinion of lawyers is taken at face value, but no, it seems that some core
Git contributors seem to disagree with the lawyers in favor of their own
opinion...)
Several participants found language and proofreading assistance useful. A
particular concern was submissions where the human does little more than
relay agent output, leaving reviewers to deal with the consequences. The
influx of poor GSoC contributions was one example. Attribution such as
Assisted-by was suggested to make tool use clearer, but attribution alone
does not answer the quality or DCO questions. (Personal note: my precedent
of "Assisted-by" was called out as helpful, and I do think it is. I make a
difference between AI-generated and AI-assisted. I'm not a fast typer, so
I benefit a lot from being able to tell an LLM to please refactor out
these four lines with the appropriate signature. There's not much
creativity in there. I also like to let AI present me the call graphs for
certain code locations, because due to the choice of C, which thanks to
the C preprocessor is not easy to analyze statically, there are no
competent tools other than LLMs that I can use for the task. I was highly
surprised, though, to see how much enmity against AI in general was
voiced, not by many, but many, many times, and how that contrasts with the
Linux project which I hitherto had not considered to be as particularly
open to modern practices.)
brian and Taylor agreed to put differing policy proposals on the list. The
suggested process is to have alternatives examined by SFC counsel, make
the risks clear, and then consider a vote. Emily volunteered to organize
the voting procedure. Eligibility and the details remain open; Junio's
authority as maintainer remains central. (Personal note: Since Taylor
works for OpenAI now, I was not surprised by his stance, but brian works
at GitHub, home of GitHub Copilot, and I am not sure how favorable their
employer would look at their semi-public utterings about AI...)
Protocol v2 for pushes
There are concrete use cases now: repositories with millions of refs,
including a reported 896 MB ref advertisement. Reftable improves ref
update throughput, but does not by itself solve the advertisement problem.
Nobody objected to push protocol v2, and the fetch-v2 infrastructure
already provides much of the foundation.
The discussion covered advertising fewer refs, letting clients identify
useful branches, and replacing large advertisements with a few rounds of
push negotiation. Negotiation results could also help optimize the
server's connectivity checks. Some improvements might be possible in the
existing protocol before introducing v2.
We need to measure the tradeoffs rather than assume fewer bytes means
faster pushes. One example involved a shallow push taking 35 seconds
instead of two because of work to minimize the transfer. Shallow
boundaries and unrelated histories complicate the proposed heuristics.
SHA-256 interoperability is another reason to want push v2: the current
push protocol requires using the server's primary hash algorithm.
Negotiation could make that more flexible.
Forge replication to thousands of mirrors would benefit from finding out
cheaply whether refs have changed, rather than downloading full
advertisements from every target. Checksums, ETag-like values, and
reftable generation numbers were discussed, with concurrent updates
complicating the picture.
Compact or compressed advertisements are also worth exploring and
benchmarking, possibly reusing reftable's format. That does not mean
sending the server's actual reftable, including hidden refs. There are
several promising directions here, but no final design yet.
Some breakout sessions were planned, but apparently had to be cut.
Personal notes: I wasn't present for all of the sessions, in the afternoon
I had other commitments; Therefore these notes (which AI assisted me in
distilling) came partially from what I dictated and partially from the
shared Google Document in which a few volunteers gracefully wrote notes. I
found it challenging to connect as a remote participant. The link to the
Google Meet, as well as control over the lobby thereof, seems to have been
restricted to at most a few people, which might have contributed to the
long waiting time before I was allowed in, and it definitely contributed
to my comments not reaching the discussion in time to have an impact. I
would have loved for Junio or the other two brave souls who also
participated remotedly to have had more "air time". I am still a fan of
the idea to have more frequent, smaller, virtual Contributor Summits,
organized by a rotating cast. (Maybe I can get Emily to host the next
one.) I was very happy that Junio was participating, as he _is_ the
project lead, and in past Contributor Summits decisions were taken without
him, which I found odd. Timing was really challenging for him, though, it
was way past midnight for him. I'm all the more grateful that he
did participate.
Final remark: This summary is obviously biased. I lightly edited it to
separate better between my personal views and a hopefully unbiased account
of what was discussed, and how, and by who. Nevertheless, I am but human.
As a consequence, I would be delighted if other participants would share
their summaries, so that my bias can be balanced out.
Ciao,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
@ 2026-09-23 11:55 ` Daniele Sassoli
2026-09-24 12:31 ` Johannes Schindelin
2026-09-25 9:53 ` Luca Milanesio
2026-09-23 12:52 ` D. Ben Knoble
` (2 subsequent siblings)
3 siblings, 2 replies; 21+ messages in thread
From: Daniele Sassoli @ 2026-09-23 11:55 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Hi Johannes,
Thanks so much for this summary, I didn't participate at the contributor
summit
as I was leading one of the breakout sessions in the morning and had a
plane to
catch in the afternoon, so I'm very grateful of your summary.
On 22/09/2026 19:44, Johannes Schindelin wrote:
> Hi Junio,
>
> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>
>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>> feature topics to be ready before the final, so most of the
>>>> in-flight topics will stay cooking in 'next' until then. As
>>>> discussed at the Git Contributors' Summit, the version after the
>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>> year.
>>> Would you say that the following is an accurate characterization of the
>>> timeline, so that people who need to plan dependent projects can rely on
>>> it?
>> My outline was deliberately limited up to end of this year as I am
>> hesitant to say beyond that point before the meeting notes are made
>> public.
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
>
> Security mailing list and process
>
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive. No fixed release cadence or guaranteed response
> time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability. (Personal note, not
> discussed at the Summit: Stolee had tried to start a conversation about
> Git's security boundary a long time ago, but nobody replied. Maybe the AI
> onslaught will provide enough motivation to get that discussion going.)
> Moving non-security bugs to the public list more readily was also
> encouraged. A timeout after which public discussion would be presumed OK
> was proposed, but not agreed.
>
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern. Using AI for triage or fixes raises confidentiality and
> DCO questions of its own. (Personal note: There seemed to be some
> sentiment in the room that contradicted the earlier agreed-on finding on
> the mailing list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
>
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated. Sure, there are the expected
> merge conflicts when merging `maint-*` branches, and running -- and
> fixing! -- CI on all of the tags in a private repository should go without
> saying, but that's all craft of the trade. Rather, the indecision and lack
> of engagement on the git-security mailing list is what I see as the
> blocker. I'd happily volunteer to juggle those branch thickets if that was
> truly the make-or-break issue here.)
>
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising, as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline. It's not really that big
> of a deal. Testing patches, constructive feedback, these are the things
> that are missing and therefore blocking the process. I sensed a lot of
> finger-pointing in this discussion. I mean, I don't blame anybody for
> avoiding security work: it is stressful and intense. The responsibility
> for getting things wrong is enormous. I know that because I've done my
> share of that, probably more than most in the Git project, and I will do
> even more in the future. But when I don't have the time, or the energy, I
> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>
> SHA-256 support across the ecosystem had been a blocker. GitHub reported
> experimental support, with general availability expected around November.
> GitLab already had public, non-experimental support, and libgit2 supports
> it, too. JGit remains a gap; Google was not planning to fund that work.
>
> The SHA-1/SHA-256 interoperability work, including historical tags, was
> reported to be implemented but not yet sent to the list. (Personal note: I
> think that the room seriously "mis-underestimated" the real-world impact
> of this. The code is not even on the Git mailing list, and the
> ramifications of not having a robust plan how to deal with partial clones
> or submodules or even signed tags strikes me as a dealbreaker. I would not
> be surprised if the decision to enforce SHA-256 as default would have to
> be revisited before v3.0, and possibly overturned.)
>
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
>
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
>
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
>
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages, and privacy-respecting traffic measurements to help
> prioritize documentation work. No diagram format was chosen, and caching
> and AI scraping complicate getting useful traffic data. Mermaid was
> proposed, and even GraphViz. (Personal note: I added support for Mermaid
> diagrams to https://git-scm.com/, but it turned out to be too limited, so
> I added GraphViz support. The support code for this is a bit of a beast,
> having a wasm version of GraphViz for development, pre-rendering the
> diagrams as SVG and as PDF during deployment of the site; it was quite a
> bit of fun to implement all that.)
>
> Outreachy sponsoring
>
> The goal is to support three interns in the round starting in early
> December, at $10,000 each. The corporate sponsorship previously provided
> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
> company contacts to follow up with; Emily offered to ask Google's OSPO,
> without high expectations. No new sponsorship commitments were made.
> (Personal note: I don't think that these internships provide enough
> publicity to give companies much of an incentive to fund this. Which I
> find a bit of a shame, Outreachy in particular does a lot of important,
> good work, and if I wasn't so constantly overworked, I would want to
> mentor again; I always found it rewarding, even if I hold myself to a
> quite high bar which is quite draining.)
>
> A related point for Git Merge 2027: announcing the location early would
> help Outreachy and GSoC interns plan attendance. No location was selected.
>
> Pluggable object database
>
> Patrick's pluggable object database is working, but it is not complete:
> commit-graph and multi-pack-index integration are still outstanding, and a
> repository extension is planned. (Personal note: It might be interesting
> to see whether implementing a storage backend is easier in core Git or in
> another Git-compatible implementation. JGit should be a natural target,
> having originated within BigTable-sized constraints, i.e. a different
> storage system, but funding seems to have dried up, there's not even
> SHA-256 support, so JGit might not be as hackable as it once was.)
Pluggable backend implementations for JGit have been possible for quite some
time, although, admittedly, I don't think any made it to production.
Maybe at
the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it
wasn't
fashionable yet and so the project was never carried forward. I know Luca
submitted a talk for the Gerrit User Summit to present a Cassandra
back-end, for
which I can see conversation started 10 years ago[2].
Regarding JGit support's for SHA256, I know some corporations have had
interest
in sponsoring this work and have discussed potentially implementing
together it
with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is
still
very much developed and kept up to date with great effort from the
community, so
I believe it to still be as hackable as it was, there just hasn't been
enough
interest for SHA-256 yet, which I agree is a shame, hopefully in the
near future
this gets remediated.
[1] https://github.com/spearce/jgit_cassandra
[2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
>
> Content-defined chunking prompted an important distinction between
> changing how objects are stored and changing the logical object model.
> Starting at the storage layer would let us preserve existing blob OIDs
> rather than require ecosystem-wide changes. A new pack/index format could
> provide another representation of the same object, much as deltas do
> today. No particular representation was agreed. (Personal note: It is
> curious to me why nobody tought about inventing a "meta blob", i.e. an
> object much like a tree object, except that it stitches together a larger
> blob. This would allow for the content-defined chunking that `rsync`
> already championed, way before Git was born! It would have allowed a Git
> native large file support worth writing home about, and could have
> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
> not have had to be invented, and it would have allowed game development to
> move to Git. I can only imagine that the time it would cost to get even
> the first patches of this into core Git would be seen as prohibitive by
> any company who may have considered the effort.)
>
> There is also an API question: does a backend seeing only object content
> have enough context to make good storage and delta choices, or should it
> receive richer information? More searchable tree storage and a Git "commit
> cloud" were other possibilities raised, not committed plans. (Personal
> note: At a previous GitMerge, Facebook presented their work, see e.g.
> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
> which includes separating actual storage from transport. That is, already
> at push time, derived metadata is computed in async jobs which provide
> several potential deltas ready-to-go when a client clones or fetches. They
> reported clones with regular Git clients that are twice as fast, just
> because the server doesn't need to spend much compute on the data it
> sends. So there is a lot to be learned out there already.)
>
> AI
>
> The current SubmittingPatches policy is rooted in DCO certification and
> advice from SFC lawyers. The unresolved question is whether, and to what
> extent, contributors can certify AI-generated code. There was substantial
> disagreement about acceptable use, provenance and legal risks, community
> trust, review burden, and whether the current caution excludes useful
> tools. No policy change was agreed. (Personal note: You'd think that the
> opinion of lawyers is taken at face value, but no, it seems that some core
> Git contributors seem to disagree with the lawyers in favor of their own
> opinion...)
>
> Several participants found language and proofreading assistance useful. A
> particular concern was submissions where the human does little more than
> relay agent output, leaving reviewers to deal with the consequences. The
> influx of poor GSoC contributions was one example. Attribution such as
> Assisted-by was suggested to make tool use clearer, but attribution alone
> does not answer the quality or DCO questions. (Personal note: my precedent
> of "Assisted-by" was called out as helpful, and I do think it is. I make a
> difference between AI-generated and AI-assisted. I'm not a fast typer, so
> I benefit a lot from being able to tell an LLM to please refactor out
> these four lines with the appropriate signature. There's not much
> creativity in there. I also like to let AI present me the call graphs for
> certain code locations, because due to the choice of C, which thanks to
> the C preprocessor is not easy to analyze statically, there are no
> competent tools other than LLMs that I can use for the task. I was highly
> surprised, though, to see how much enmity against AI in general was
> voiced, not by many, but many, many times, and how that contrasts with the
> Linux project which I hitherto had not considered to be as particularly
> open to modern practices.)
>
> brian and Taylor agreed to put differing policy proposals on the list. The
> suggested process is to have alternatives examined by SFC counsel, make
> the risks clear, and then consider a vote. Emily volunteered to organize
> the voting procedure. Eligibility and the details remain open; Junio's
> authority as maintainer remains central. (Personal note: Since Taylor
> works for OpenAI now, I was not surprised by his stance, but brian works
> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
> employer would look at their semi-public utterings about AI...)
>
> Protocol v2 for pushes
>
> There are concrete use cases now: repositories with millions of refs,
> including a reported 896 MB ref advertisement. Reftable improves ref
> update throughput, but does not by itself solve the advertisement problem.
> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
> already provides much of the foundation.
>
> The discussion covered advertising fewer refs, letting clients identify
> useful branches, and replacing large advertisements with a few rounds of
> push negotiation. Negotiation results could also help optimize the
> server's connectivity checks. Some improvements might be possible in the
> existing protocol before introducing v2.
>
> We need to measure the tradeoffs rather than assume fewer bytes means
> faster pushes. One example involved a shallow push taking 35 seconds
> instead of two because of work to minimize the transfer. Shallow
> boundaries and unrelated histories complicate the proposed heuristics.
>
> SHA-256 interoperability is another reason to want push v2: the current
> push protocol requires using the server's primary hash algorithm.
> Negotiation could make that more flexible.
>
> Forge replication to thousands of mirrors would benefit from finding out
> cheaply whether refs have changed, rather than downloading full
> advertisements from every target. Checksums, ETag-like values, and
> reftable generation numbers were discussed, with concurrent updates
> complicating the picture.
>
> Compact or compressed advertisements are also worth exploring and
> benchmarking, possibly reusing reftable's format. That does not mean
> sending the server's actual reftable, including hidden refs. There are
> several promising directions here, but no final design yet.
>
> Some breakout sessions were planned, but apparently had to be cut.
>
> Personal notes: I wasn't present for all of the sessions, in the afternoon
> I had other commitments; Therefore these notes (which AI assisted me in
> distilling) came partially from what I dictated and partially from the
> shared Google Document in which a few volunteers gracefully wrote notes. I
> found it challenging to connect as a remote participant. The link to the
> Google Meet, as well as control over the lobby thereof, seems to have been
> restricted to at most a few people, which might have contributed to the
> long waiting time before I was allowed in, and it definitely contributed
> to my comments not reaching the discussion in time to have an impact. I
> would have loved for Junio or the other two brave souls who also
> participated remotedly to have had more "air time". I am still a fan of
> the idea to have more frequent, smaller, virtual Contributor Summits,
> organized by a rotating cast. (Maybe I can get Emily to host the next
> one.) I was very happy that Junio was participating, as he _is_ the
> project lead, and in past Contributor Summits decisions were taken without
> him, which I found odd. Timing was really challenging for him, though, it
> was way past midnight for him. I'm all the more grateful that he
> did participate.
>
> Final remark: This summary is obviously biased. I lightly edited it to
> separate better between my personal views and a hopefully unbiased account
> of what was discussed, and how, and by who. Nevertheless, I am but human.
> As a consequence, I would be delighted if other participants would share
> their summaries, so that my bias can be balanced out.
>
> Ciao,
> Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-23 11:55 ` Daniele Sassoli
@ 2026-09-24 12:31 ` Johannes Schindelin
2026-09-25 9:53 ` Luca Milanesio
1 sibling, 0 replies; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-24 12:31 UTC (permalink / raw)
To: Daniele Sassoli; +Cc: Junio C Hamano, git
Hi Daniele,
On Wed, 23 Sep 2026, Daniele Sassoli wrote:
> Thanks so much for this summary, I didn't participate at the contributor
> summit as I was leading one of the breakout sessions in the morning and
> had a plane to catch in the afternoon, so I'm very grateful of your
> summary.
I'm glad it was helpful!
> On 22/09/2026 19:44, Johannes Schindelin wrote:
>
> [... snip ...]
> > Pluggable object database
> >
> > Patrick's pluggable object database is working, but it is not
> > complete: commit-graph and multi-pack-index integration are still
> > outstanding, and a repository extension is planned. (Personal note: It
> > might be interesting to see whether implementing a storage backend is
> > easier in core Git or in another Git-compatible implementation. JGit
> > should be a natural target, having originated within BigTable-sized
> > constraints, i.e. a different storage system, but funding seems to
> > have dried up, there's not even SHA-256 support, so JGit might not be
> > as hackable as it once was.)
>
> Pluggable backend implementations for JGit have been possible for quite
> some time, although, admittedly, I don't think any made it to
> production. Maybe at the time when this was introduced(16 years ago!!)
> by Shawn[1] in JGit it wasn't fashionable yet and so the project was
> never carried forward. I know Luca submitted a talk for the Gerrit User
> Summit to present a Cassandra back-end, for which I can see conversation
> started 10 years ago[2].
>
> Regarding JGit support's for SHA256, I know some corporations have had
> interest in sponsoring this work and have discussed potentially
> implementing together it with GerritForge, but, as far as I know, work
> isn't ongoing yet. JGit is still very much developed and kept up to date
> with great effort from the community, so I believe it to still be as
> hackable as it was, there just hasn't been enough interest for SHA-256
> yet, which I agree is a shame, hopefully in the near future this gets
> remediated.
>
> [1] https://github.com/spearce/jgit_cassandra
> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
I'm glad to hear that JGit isn't stalled, even though I doubt that the
SHA-256 support could be done without any corporate support.
Ciao,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-23 11:55 ` Daniele Sassoli
2026-09-24 12:31 ` Johannes Schindelin
@ 2026-09-25 9:53 ` Luca Milanesio
1 sibling, 0 replies; 21+ messages in thread
From: Luca Milanesio @ 2026-09-25 9:53 UTC (permalink / raw)
To: git
Thanks Johannes for the detailed summary,
See below some additions on the storage backend in JGit below.
> On 23 Sep 2026, at 12:55, Daniele Sassoli <danielesassoli@gmail.com> wrote:
>
> Hi Johannes,
>
> Thanks so much for this summary, I didn't participate at the contributor summit
> as I was leading one of the breakout sessions in the morning and had a plane to
> catch in the afternoon, so I'm very grateful of your summary.
>
> On 22/09/2026 19:44, Johannes Schindelin wrote:
>> Hi Junio,
>>
>> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>>
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>>
>>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>>> feature topics to be ready before the final, so most of the
>>>>> in-flight topics will stay cooking in 'next' until then. As
>>>>> discussed at the Git Contributors' Summit, the version after the
>>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>>> year.
>>>> Would you say that the following is an accurate characterization of the
>>>> timeline, so that people who need to plan dependent projects can rely on
>>>> it?
>>> My outline was deliberately limited up to end of this year as I am
>>> hesitant to say beyond that point before the meeting notes are made
>>> public.
>> I originally wrote this summary of the Git Contributor Summit only for my
>> own records, but since you hinted at wanting some meeting notes, figured
>> it might be interesting to other people, too. So here goes my distillation
>> of the breakout-sessions from this year's Contributors' Summit. Many of
>> these ideas still need discussion on the list; proposals below are not
>> project-wide decisions.
>>
>> Security mailing list and process
>>
>> The security list is seeing a large influx of outside reports, apparently
>> often AI-assisted or generated. Duplicates and reports outside Git's
>> security model consume triage time, while some patches have waited for
>> months. Waiting for an empty queue is not a workable release criterion: we
>> need to release the fixes we have, rather than hold them indefinitely
>> while more reports arrive. No fixed release cadence or guaranteed response
>> time was settled.
>>
>> Documenting Git's security model would save repeated explanations of what
>> does and does not constitute a vulnerability. (Personal note, not
>> discussed at the Summit: Stolee had tried to start a conversation about
>> Git's security boundary a long time ago, but nobody replied. Maybe the AI
>> onslaught will provide enough motivation to get that discussion going.)
>> Moving non-security bugs to the public list more readily was also
>> encouraged. A timeout after which public discussion would be presumed OK
>> was proposed, but not agreed.
>>
>> More company staffing would help, without turning this into an obligation
>> for volunteers. Paying for dedicated help was discussed, with onboarding
>> costs a concern. Using AI for triage or fixes raises confidentiality and
>> DCO questions of its own. (Personal note: There seemed to be some
>> sentiment in the room that contradicted the earlier agreed-on finding on
>> the mailing list that using AI for triaging and for investigating wasn't a
>> copyright concern and should therefore be considered permissible.)
>>
>> The release bottleneck is not really tag automation. Merging and
>> backporting fixes, preparing advisories, and handling CVEs take work, and
>> too much of that knowledge lives in people's heads. Peff volunteered to
>> start a public discussion of the process and dig up existing resources.
>> (Personal note: I have done that merging, backporting, etc plenty of
>> times, and I don't think that it is the bottleneck, and I was rather
>> surprised to hear that it is complicated. Sure, there are the expected
>> merge conflicts when merging `maint-*` branches, and running -- and
>> fixing! -- CI on all of the tags in a private repository should go without
>> saying, but that's all craft of the trade. Rather, the indecision and lack
>> of engagement on the git-security mailing list is what I see as the
>> blocker. I'd happily volunteer to juggle those branch thickets if that was
>> truly the make-or-break issue here.)
>>
>> Microsoft's release process reportedly needs about seven weeks. There were
>> no objections in the room to proceeding without waiting for that schedule.
>> (Personal note: That release process was misrepresented, which is
>> surprising, as I coordinated two or three Git for Windows security bugfix
>> releases _on the git-security list_ since the most recent Git security
>> bugfix release, it's always the same thing: release on a second Tuesday of
>> the month, three weeks before that the patches need to have settled,
>> everybody goes home with a dependable timeline. It's not really that big
>> of a deal. Testing patches, constructive feedback, these are the things
>> that are missing and therefore blocking the process. I sensed a lot of
>> finger-pointing in this discussion. I mean, I don't blame anybody for
>> avoiding security work: it is stressful and intense. The responsibility
>> for getting things wrong is enormous. I know that because I've done my
>> share of that, probably more than most in the Git project, and I will do
>> even more in the future. But when I don't have the time, or the energy, I
>> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>>
>> Git v3.0
>>
>> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
>> December, then v2.99 and v3.0 next spring. The jump in version numbers is
>> intended to signal the approaching breaking changes. March and April were
>> both mentioned; the precise timing is not settled.
>>
>> There was agreement on releasing v2.99.1 and v3.0 together, differing only
>> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
>> separate from another round of feature development. Nobody in the room
>> objected to Rust becoming mandatory in v3.0. (Personal note: probably
>> because Randall wasn't there, to say that NonStop support would be a
>> blocker and that Git please wait.) A v2.x LTS remains an open question,
>> with Gentoo mentioned as an interested party. (Personal note: I am still
>> advocating for an in-tree Long Term Support branch, and since Junio
>> indicated that he's less than eager to take care of that, I would love for
>> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
>> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>>
>> SHA-256 support across the ecosystem had been a blocker. GitHub reported
>> experimental support, with general availability expected around November.
>> GitLab already had public, non-experimental support, and libgit2 supports
>> it, too. JGit remains a gap; Google was not planning to fund that work.
>>
>> The SHA-1/SHA-256 interoperability work, including historical tags, was
>> reported to be implemented but not yet sent to the list. (Personal note: I
>> think that the room seriously "mis-underestimated" the real-world impact
>> of this. The code is not even on the Git mailing list, and the
>> ramifications of not having a robust plan how to deal with partial clones
>> or submodules or even signed tags strikes me as a dealbreaker. I would not
>> be surprised if the decision to enforce SHA-256 as default would have to
>> be revisited before v3.0, and possibly overturned.)
>>
>> Documentation
>>
>> Julia's work highlights the gap between documentation written by people
>> who know Git inside out and users who do not yet know what objects, the
>> index, or upstream mean. We need approachable learning material as well as
>> reference documentation. Both need work; keeping manpages concise does not
>> mean they cannot have better explanations and examples. (Personal note: I
>> am beyond excited that Julia, whose work I have always admired, got
>> interested in improving Git's documentation, which is in dear need of
>> being improved, mainly because it does not cater to the majority of Git
>> users out there who are unlikely to wander onto the Git mailing list,
>> ever. I just hope that old-timers who really do not need the documentation
>> nor understand the need of those who do need it show enough appreciation
>> for the fresh views and for Julia's understanding of the target audience.)
>>
>> Discoverability matters, too. The website (https://git-scm.com/) needs
>> clearer entry points for learning Git, and existing guides are harder to
>> find than manpages. Missing subsection links are another improvement we
>> could make incrementally. (Personal note: Judging by the history of that
>> site, I do wonder whether the core Git contributors are interested in
>> helping this effort at all. For example, there are a growing number of PRs
>> suggesting to add new UIs to the growing list, but I gave up reviewing
>> them because I was the only one doing so.)
>>
>> There was support for replacing outdated material and for merging useful
>> improvements, then iterating, rather than trying to perfect everything
>> before it lands. Bringing user feedback to the list without flooding it
>> remains a challenge.
>>
>> The current funding covers only 100 hours split between two people.
>> Additional project and company funding was encouraged; brian, Emily, and
>> Mark offered to explore company support. (Personal note: I had tried, back
>> when GitHub still funded my team, to start something like that, without
>> any success. To the contrary, even Git for Windows and Git Credential
>> Manager got defunded.)
>>
>> On the tooling side, using only Asciidoctor instead of maintaining both
>> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
>> change. Distribution support and rendering differences need checking, with
>> doc-diff suggested for comparing the outputs. Patrick filed an issue
>> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
>> maintained by Asciidoctor, and I am aware already of one change that was
>> made to the spec without adapting AsciiDoc accordingly. So the entire
>> discussion might be quite moot already.)
>>
>> Other ideas included richer diagrams for HTML while retaining text
>> versions for manpages, and privacy-respecting traffic measurements to help
>> prioritize documentation work. No diagram format was chosen, and caching
>> and AI scraping complicate getting useful traffic data. Mermaid was
>> proposed, and even GraphViz. (Personal note: I added support for Mermaid
>> diagrams to https://git-scm.com/, but it turned out to be too limited, so
>> I added GraphViz support. The support code for this is a bit of a beast,
>> having a wasm version of GraphViz for development, pre-rendering the
>> diagrams as SVG and as PDF during deployment of the site; it was quite a
>> bit of fun to implement all that.)
>>
>> Outreachy sponsoring
>>
>> The goal is to support three interns in the round starting in early
>> December, at $10,000 each. The corporate sponsorship previously provided
>> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
>> company contacts to follow up with; Emily offered to ask Google's OSPO,
>> without high expectations. No new sponsorship commitments were made.
>> (Personal note: I don't think that these internships provide enough
>> publicity to give companies much of an incentive to fund this. Which I
>> find a bit of a shame, Outreachy in particular does a lot of important,
>> good work, and if I wasn't so constantly overworked, I would want to
>> mentor again; I always found it rewarding, even if I hold myself to a
>> quite high bar which is quite draining.)
>>
>> A related point for Git Merge 2027: announcing the location early would
>> help Outreachy and GSoC interns plan attendance. No location was selected.
>>
>> Pluggable object database
>>
>> Patrick's pluggable object database is working, but it is not complete:
>> commit-graph and multi-pack-index integration are still outstanding, and a
>> repository extension is planned. (Personal note: It might be interesting
>> to see whether implementing a storage backend is easier in core Git or in
>> another Git-compatible implementation. JGit should be a natural target,
>> having originated within BigTable-sized constraints, i.e. a different
>> storage system, but funding seems to have dried up, there's not even
>> SHA-256 support, so JGit might not be as hackable as it once was.)
> Pluggable backend implementations for JGit have been possible for quite some
> time, although, admittedly, I don't think any made it to production.
I'd like to provide some context here, as several pluggable JGit storage
implementations are actually running in highly demanding production
environments today.
First, the Git servers at Google (including gerrit.googlesource.com) are
powered by a custom, pluggable JGit storage backend built on top of Google's
internal data-center storage. While the backend implementation itself is
proprietary, it relies entirely on the exact same JGit classes and pluggable
interfaces available in the open-source project. It has been operating
smoothly at a massive scale for over a decade.
Second, there is a highly successful open-source implementation focusing on the
ref-db layer of Git storage. Developed by GerritForge over six years ago and
donated to the AOSP project (see the GitHub mirror at [3]), this backend is
used daily in several large, multi-site Gerrit deployments worldwide. It allows
for globally consistent updates of Git repository refs across distributed
remote sites.
Third, regarding the implementation mentioned by Dani [2]: while it captured
attention 10 years ago, without seeing immediate adoption, I suspect the timing simply
preceded the current appetite for AI-generated code. The demand is entirely
different now. The architectural foundation Google built into JGit over 16
years ago is perfectly positioned to support these kinds of modern innovations.
It is genuinely exciting to see the core Git project moving in this same
direction with Patrick's work. Pluggability has always been a core strength of
JGit's design, and seeing the broader ecosystem embrace this abstraction is a
huge win for all of us.
[3] (github.com/GerritCodeReview/modules_global-refdb)
Luca
> Maybe at
> the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it wasn't
> fashionable yet and so the project was never carried forward. I know Luca
> submitted a talk for the Gerrit User Summit to present a Cassandra back-end, for
> which I can see conversation started 10 years ago[2].
>
> Regarding JGit support's for SHA256, I know some corporations have had interest
> in sponsoring this work and have discussed potentially implementing together it
> with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is still
> very much developed and kept up to date with great effort from the community, so
> I believe it to still be as hackable as it was, there just hasn't been enough
> interest for SHA-256 yet, which I agree is a shame, hopefully in the near future
> this gets remediated.
>
> [1] https://github.com/spearce/jgit_cassandra
> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
>>
>> Content-defined chunking prompted an important distinction between
>> changing how objects are stored and changing the logical object model.
>> Starting at the storage layer would let us preserve existing blob OIDs
>> rather than require ecosystem-wide changes. A new pack/index format could
>> provide another representation of the same object, much as deltas do
>> today. No particular representation was agreed. (Personal note: It is
>> curious to me why nobody tought about inventing a "meta blob", i.e. an
>> object much like a tree object, except that it stitches together a larger
>> blob. This would allow for the content-defined chunking that `rsync`
>> already championed, way before Git was born! It would have allowed a Git
>> native large file support worth writing home about, and could have
>> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
>> not have had to be invented, and it would have allowed game development to
>> move to Git. I can only imagine that the time it would cost to get even
>> the first patches of this into core Git would be seen as prohibitive by
>> any company who may have considered the effort.)
>>
>> There is also an API question: does a backend seeing only object content
>> have enough context to make good storage and delta choices, or should it
>> receive richer information? More searchable tree storage and a Git "commit
>> cloud" were other possibilities raised, not committed plans. (Personal
>> note: At a previous GitMerge, Facebook presented their work, see e.g.
>> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
>> which includes separating actual storage from transport. That is, already
>> at push time, derived metadata is computed in async jobs which provide
>> several potential deltas ready-to-go when a client clones or fetches. They
>> reported clones with regular Git clients that are twice as fast, just
>> because the server doesn't need to spend much compute on the data it
>> sends. So there is a lot to be learned out there already.)
>>
>> AI
>>
>> The current SubmittingPatches policy is rooted in DCO certification and
>> advice from SFC lawyers. The unresolved question is whether, and to what
>> extent, contributors can certify AI-generated code. There was substantial
>> disagreement about acceptable use, provenance and legal risks, community
>> trust, review burden, and whether the current caution excludes useful
>> tools. No policy change was agreed. (Personal note: You'd think that the
>> opinion of lawyers is taken at face value, but no, it seems that some core
>> Git contributors seem to disagree with the lawyers in favor of their own
>> opinion...)
>>
>> Several participants found language and proofreading assistance useful. A
>> particular concern was submissions where the human does little more than
>> relay agent output, leaving reviewers to deal with the consequences. The
>> influx of poor GSoC contributions was one example. Attribution such as
>> Assisted-by was suggested to make tool use clearer, but attribution alone
>> does not answer the quality or DCO questions. (Personal note: my precedent
>> of "Assisted-by" was called out as helpful, and I do think it is. I make a
>> difference between AI-generated and AI-assisted. I'm not a fast typer, so
>> I benefit a lot from being able to tell an LLM to please refactor out
>> these four lines with the appropriate signature. There's not much
>> creativity in there. I also like to let AI present me the call graphs for
>> certain code locations, because due to the choice of C, which thanks to
>> the C preprocessor is not easy to analyze statically, there are no
>> competent tools other than LLMs that I can use for the task. I was highly
>> surprised, though, to see how much enmity against AI in general was
>> voiced, not by many, but many, many times, and how that contrasts with the
>> Linux project which I hitherto had not considered to be as particularly
>> open to modern practices.)
>>
>> brian and Taylor agreed to put differing policy proposals on the list. The
>> suggested process is to have alternatives examined by SFC counsel, make
>> the risks clear, and then consider a vote. Emily volunteered to organize
>> the voting procedure. Eligibility and the details remain open; Junio's
>> authority as maintainer remains central. (Personal note: Since Taylor
>> works for OpenAI now, I was not surprised by his stance, but brian works
>> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
>> employer would look at their semi-public utterings about AI...)
>>
>> Protocol v2 for pushes
>>
>> There are concrete use cases now: repositories with millions of refs,
>> including a reported 896 MB ref advertisement. Reftable improves ref
>> update throughput, but does not by itself solve the advertisement problem.
>> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
>> already provides much of the foundation.
>>
>> The discussion covered advertising fewer refs, letting clients identify
>> useful branches, and replacing large advertisements with a few rounds of
>> push negotiation. Negotiation results could also help optimize the
>> server's connectivity checks. Some improvements might be possible in the
>> existing protocol before introducing v2.
>>
>> We need to measure the tradeoffs rather than assume fewer bytes means
>> faster pushes. One example involved a shallow push taking 35 seconds
>> instead of two because of work to minimize the transfer. Shallow
>> boundaries and unrelated histories complicate the proposed heuristics.
>>
>> SHA-256 interoperability is another reason to want push v2: the current
>> push protocol requires using the server's primary hash algorithm.
>> Negotiation could make that more flexible.
>>
>> Forge replication to thousands of mirrors would benefit from finding out
>> cheaply whether refs have changed, rather than downloading full
>> advertisements from every target. Checksums, ETag-like values, and
>> reftable generation numbers were discussed, with concurrent updates
>> complicating the picture.
>>
>> Compact or compressed advertisements are also worth exploring and
>> benchmarking, possibly reusing reftable's format. That does not mean
>> sending the server's actual reftable, including hidden refs. There are
>> several promising directions here, but no final design yet.
>>
>> Some breakout sessions were planned, but apparently had to be cut.
>>
>> Personal notes: I wasn't present for all of the sessions, in the afternoon
>> I had other commitments; Therefore these notes (which AI assisted me in
>> distilling) came partially from what I dictated and partially from the
>> shared Google Document in which a few volunteers gracefully wrote notes. I
>> found it challenging to connect as a remote participant. The link to the
>> Google Meet, as well as control over the lobby thereof, seems to have been
>> restricted to at most a few people, which might have contributed to the
>> long waiting time before I was allowed in, and it definitely contributed
>> to my comments not reaching the discussion in time to have an impact. I
>> would have loved for Junio or the other two brave souls who also
>> participated remotedly to have had more "air time". I am still a fan of
>> the idea to have more frequent, smaller, virtual Contributor Summits,
>> organized by a rotating cast. (Maybe I can get Emily to host the next
>> one.) I was very happy that Junio was participating, as he _is_ the
>> project lead, and in past Contributor Summits decisions were taken without
>> him, which I found odd. Timing was really challenging for him, though, it
>> was way past midnight for him. I'm all the more grateful that he
>> did participate.
>>
>> Final remark: This summary is obviously biased. I lightly edited it to
>> separate better between my personal views and a hopefully unbiased account
>> of what was discussed, and how, and by who. Nevertheless, I am but human.
>> As a consequence, I would be delighted if other participants would share
>> their summaries, so that my bias can be balanced out.
>>
>> Ciao,
>> Johannes
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
@ 2026-09-23 12:52 ` D. Ben Knoble
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
3 siblings, 0 replies; 21+ messages in thread
From: D. Ben Knoble @ 2026-09-23 12:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On Tue, Sep 22, 2026 at 2:45 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
Thanks for this!
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
If you are able/willing to point me towards the [relevant] Gentoo
folks, I'd love to chat
with them. It's been my distribution of choice for the last year and, while I've
helped some on the "packaging Git" side, I have to imagine the 2.x request comes
more from thinking about the surrounding things Git is used for (both developing
the system and running it, such as the 3rd-party repository syncs or live
package installs that use Git).
Anyway, I'd like to help them out :)
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
Don't forget that Julia received a grant to continue working on docs!
https://www.sovereign.tech/news/meet-the-2026-sovereign-tech-fellows
> Protocol v2 for pushes
Did I understand correctly from a recent discussion that v2 also requires more
"setup" and is thus not easy to use for smaller "local" hosts? If so, making it
more accessible might also be nice.
> I am still a fan of the idea to have more frequent, smaller, virtual
> Contributor Summits, organized by a rotating cast. (Maybe I can get Emily to
> host the next one.)
In other projects I've participated in, more frequent smaller check-ins have
been helpful. It also feels less icky to miss one for whatever reason, since the
next one is not too far off!
--
D. Ben Knoble
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
2026-09-23 12:52 ` D. Ben Knoble
@ 2026-09-23 14:22 ` Toon Claes
2026-09-24 12:38 ` Johannes Schindelin
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
3 siblings, 1 reply; 21+ messages in thread
From: Toon Claes @ 2026-09-23 14:22 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Security mailing list and process
(I decided to split up this topic into a separate mail thread)
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive.
I think we agreed on that. Because we realize the influx will not stop
any time soon.
> No fixed release cadence or guaranteed response time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability.
This is something I was planning to drive after the summit, so I agree.
> (Personal note, not discussed at the Summit: Stolee had tried to start
> a conversation about Git's security boundary a long time ago, but
> nobody replied.
I was not aware of that, maybe that happened before I started
participating there. But I'm happy to get that conversation going again.
I'll try to digg up that discussion.
> Maybe the AI onslaught will provide enough motivation to get that
> discussion going.)
Yes.
> Moving non-security bugs to the public list more readily was also
> encouraged.
That is true, but then still someone has to do the work. We're already
lacking people to work on /real/ reports, so having people to fix bugs
reported is also a staffing issue.
> A timeout after which public discussion would be presumed OK was
> proposed, but not agreed.
I'm against that, but I don't think we need to agree on that already. We
can think about this after settling the other stuff.
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern.
All I can say for now, we at GitLab plan to invest more people power
into dealing with security reports.
> Using AI for triage or fixes raises confidentiality and DCO questions
> of its own. (Personal note: There seemed to be some sentiment in the
> room that contradicted the earlier agreed-on finding on the mailing
> list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
Yeah, no consensus here. The concern wasn't as much copyright, but
passing vulnerabilities to a model, making it possibly train on that
exposing that information to who-knows-where.
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
As I pointed out during the conversation, I just don't know how to do
this.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated.
It's complicated, because we (or I at least) doesn't know how.
> Sure, there are the expected merge conflicts when merging `maint-*`
> branches, and running -- and fixing! -- CI on all of the tags in a
> private repository should go without saying, but that's all craft of
> the trade.
I'd love to learn more about this.
> Rather, the indecision and lack of engagement on the
> git-security mailing list is what I see as the blocker. I'd happily
> volunteer to juggle those branch thickets if that was truly the
> make-or-break issue here.)
I'm very grateful for that. As I mentioned (not sure that made it into
the notes), I'd love to shadow someone doing this to learn from. This
can help me get this going myself and that would distribute the load and
knowledge among more people, for which seems to be a real need.
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising
I wouldn't say this is surprising, I think most people just don't know
the details.
> as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline.
Well, thanks, that's clear.
Personally I think we can try to follow that schedule, if possible. We
currently have a few patches waiting for months to be released, and
that's not because of the Git for Windows release schedule, but more
because the lack of call to action. Those easily can get out with the
GfW cadence.
But some other cases, like the 0day Elijah has been working on this
month, I'm not sure that can wait for GfW?
> It's not really that big of a deal. Testing patches, constructive
> feedback, these are the things that are missing and therefore blocking
> the process. I sensed a lot of finger-pointing in this discussion.
I wouldn't say so, I would blame it on the lack knowledge about the
process. Or maybe that's only me speaking.
> I mean, I don't blame anybody for avoiding security work: it is
> stressful and intense. The responsibility for getting things wrong is
> enormous. I know that because I've done my share of that, probably
> more than most in the Git project, and I will do even more in the
> future.
That's why I'd like to learn from you.
> But when I don't have the time, or the energy, I am aware that
> I, myself, am the bottleneck; I don't need to blame others.)
You are not the bottleneck, or at least, you don't need to be the
bottleneck, we should set up things to spread out the load.
So I would like to suggest you and me collaborate closely to get a next
security release out and then we can go from there.
--
Laters,
Toon
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
@ 2026-09-24 12:38 ` Johannes Schindelin
0 siblings, 0 replies; 21+ messages in thread
From: Johannes Schindelin @ 2026-09-24 12:38 UTC (permalink / raw)
To: Toon Claes; +Cc: Junio C Hamano, git
Hi Toon,
On Wed, 23 Sep 2026, Toon Claes wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Security mailing list and process
> >
> > [...]
> >
> > Microsoft's release process reportedly needs about seven weeks. There
> > were no objections in the room to proceeding without waiting for that
> > schedule. (Personal note: That release process was misrepresented,
> > which is surprising
>
> I wouldn't say this is surprising, I think most people just don't know
> the details.
>
> > as I coordinated two or three Git for Windows security bugfix releases
> > _on the git-security list_ since the most recent Git security bugfix
> > release, it's always the same thing: release on a second Tuesday of
> > the month, three weeks before that the patches need to have settled,
> > everybody goes home with a dependable timeline.
>
> Well, thanks, that's clear.
>
> Personally I think we can try to follow that schedule, if possible. We
> currently have a few patches waiting for months to be released, and
> that's not because of the Git for Windows release schedule, but more
> because the lack of call to action. Those easily can get out with the
> GfW cadence.
I'm glad that you agree that Patch Tuesday isn't all _that_ much of a
friction point, this will allow some of my colleagues to relax visibly.
> [...]
>
> So I would like to suggest you and me collaborate closely to get a next
> security release out and then we can go from there.
Excellent! Let's continue this conversation in a more private setting ;-)
Ciao,
Johannes
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
` (2 preceding siblings ...)
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
@ 2026-09-23 14:40 ` Toon Claes
2026-09-23 15:15 ` Git Contributor' summit: Documentation, Junio C Hamano
3 siblings, 1 reply; 21+ messages in thread
From: Toon Claes @ 2026-09-23 14:40 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired,
I've expressed myself multiple times as well how excited I am to have
Julia working on this, but it cannot be expressed enough.
> got interested in improving Git's documentation, which is in dear need
> of being improved, mainly because it does not cater to the majority of
> Git users out there who are unlikely to wander onto the Git mailing
> list, ever. I just hope that old-timers who really do not need the
> documentation nor understand the need of those who do need it show
> enough appreciation for the fresh views and for Julia's understanding
> of the target audience.)
I think the old-timers do, but it takes skills to have a very deep
understanding and still being able to explain things to newbies.
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
I share the blame here. Some time ago I volunteered to step in to do
maintainance work on git-scm.com, but I haven't been devoting as much
time as I would like.
Talking about the UI list, that's a problem which I'm not sure worth
discussing here, but to folks interested, there is some context in the
PR[1] you created.
[1]: https://github.com/git/git-scm.com/pull/2179
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
Iteration will be key here, and I would say some steps have been taken
already. Very tiny steps though.
Finding a medium to gather user feedback is the problem. I think Discord
is a better place than the mailing list (assuming that's what you mean
by "list"?).
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages
This feels feasible. I think brian suggested to use Open Blocks[2] and
have a man-page ASCII version next to /something else/.
[2]: https://docs.asciidoctor.org/asciidoc/latest/blocks/open-blocks/
> and privacy-respecting traffic measurements to help prioritize
> documentation work.
For the record, we have been talking about this[3] in the past.
[3]: https://github.com/git/git-scm.com/issues/2054
> No diagram format was chosen
Yeah, that's the issue.
> and caching and AI scraping complicate getting useful traffic data.
> Mermaid was proposed, and even GraphViz. (Personal note: I added
> support for Mermaid diagrams to https://git-scm.com/, but it turned
> out to be too limited, so I added GraphViz support. The support code
> for this is a bit of a beast, having a wasm version of GraphViz for
> development, pre-rendering the diagrams as SVG and as PDF during
> deployment of the site; it was quite a bit of fun to implement all
> that.)
Thanks for that! They don't look bad on the cheat sheet[4].
[4]: https://git-scm.com/cheat-sheet#combine-diverged-branches
--
Laters,
Toon
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Git Contributor' summit: Documentation,
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
@ 2026-09-23 15:15 ` Junio C Hamano
0 siblings, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2026-09-23 15:15 UTC (permalink / raw)
To: Toon Claes; +Cc: Johannes Schindelin, git
Toon Claes <toon@iotcl.com> writes:
> I've expressed myself multiple times as well how excited I am to have
> Julia working on this, but it cannot be expressed enough.
;-)
>> list, ever. I just hope that old-timers who really do not need the
>> documentation nor understand the need of those who do need it show
>> enough appreciation for the fresh views and for Julia's understanding
>> of the target audience.)
>
> I think the old-timers do, but it takes skills to have a very deep
> understanding and still being able to explain things to newbies.
Not just these two skills, but you need to know what are the points
new people find hard to get when they are starting, and that is the
weakest spot for our old-timers.
>> There was support for replacing outdated material and for merging useful
>> improvements, then iterating, rather than trying to perfect everything
>> before it lands. Bringing user feedback to the list without flooding it
>> remains a challenge.
>
> Iteration will be key here, and I would say some steps have been taken
> already. Very tiny steps though.
IIRC, the view in the room was in favor of keeping and incrementally
improving the manual pages and reference material while rewriting
tutorials and material on concepts from scratch. I very much agree
with the "rewrite from scratch" part, because the concepts have
evolved and the world view have been updated even if the concepts at
the very core of the system may have not changed.
^ permalink raw reply [flat|nested] 21+ messages in thread
* What's cooking in git.git (Sep 2026, #02)
@ 2026-09-04 23:55 Junio C Hamano
2026-09-05 6:31 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
0 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2026-09-04 23:55 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and is a candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all. They may be annotated with a URL
to a message that raises issues but they are by no means exhaustive.
A topic without enough support may be discarded after a long period
of no activity (of course, it can be resubmitted when new interest
arises).
The 22nd batch of topics have now graduated to the 'master' branch.
We have 604 non-merge commits in 'master' since Git 2.55. There
are 66 non-merge commits cooking in 'next' (note that some have
been reverted), and 223 non-merge commits, including those in and
out of 'next', in 'seen' as of this writing.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* jc/history-missing-tree-errorfix (2026-09-02) 1 commit
- history: do not dereference NULL when parent tree is missing
Running "git history" in a corrupt repository can (unsurprisingly)
segfault when a necessary tree object is not found.
Will merge to 'next'?
cf. <apknMr9Jk-CzdLAR@pks.im>
source: <20260903063657.2067303-1-zkd18cjb@mail.ustc.edu.cn>
* jc/pathspec-match-const (2026-09-03) 1 commit
- pathspec: match and original in pathspec_item are const
(this branch is used by yt/pathspec-negative-prefix.)
Two members in "struct pathspec_item" were of type "char *", but
nobody updated the string through these pointers. They have been
made "const char *" instead.
Will merge to 'next'?
cf. <4439BA70-2C03-499D-B3CE-E43700C0A8DA@ytausch.de>
source: <xmqqy0dib3ue.fsf_-_@gitster.g>
* ps/tune-rerere-gc (2026-09-04) 2 commits
- builtin/maintenance: improve heuristic for "rerere gc"
- rerere: extract logic to determine whether entries are stale
"git maintenance" triggered "rerere gc" in unappropriate times and
interfered with "git rebase" etc. too much. The conditions "rerere
gc" gets triggered have been tweaked.
Will merge to 'next'?
cf. <15a488b2-b4ae-4ac8-8cb3-f06ef5bbb52b@gmail.com>
source: <20260904-b4-pks-maintenance-rerere-gc-heuristic-v2-0-b1691121fe1c@pks.im>
* as/push-force-if-includes-no-reflog (2026-09-04) 1 commit
- push: fix --force-if-includes when remote-tracking ref has no reflog
The timestamp used for checking the reflog of a remote-tracking
branch during 'git push --force-if-includes' was left uninitialized
when the reflog was completely empty, which has been corrected.
Waiting for response.
cf. <xmqqzexx58hc.fsf@gitster.g>
source: <20260904124433.12840-1-f@lex.la>
* tb/rerere-lock-grace (2026-09-04) 3 commits
- sequencer: keep auto maintenance out of the commands a sequence spawns
- sequencer: run auto maintenance once a sequence is done
- config: add git_config_append_parameter()
The sequencer machinery (used by 'git rebase', 'git cherry-pick', and
'git revert') has been updated to defer automatic maintenance tasks
until the end of the operation, preventing nested 'git commit', 'git
merge', and 'exec' commands from triggering GC operations that could
contend for locks or delete open packs while the sequence is in
progress.
Needs review.
source: <pull.2217.v2.git.1788537086.gitgitgadget@gmail.com>
--------------------------------------------------
[Stalled]
* ps/libgit-in-subdir (2026-07-12) 2 commits
. Move libgit.a sources into separate "lib/" directory
. t/helper: prepare "test-example-tap.c" for introduction of "lib/"
. Merge branch 'ps/odb-source-packed' into ps/libgit-in-subdir
The source files for 'libgit.a' have been moved into a new 'lib/'
directory to clean up the top-level directory and clearly separate
library code. This topic has been ejected for now, as it causes too
many evil merges with other topics.
Waiting for response for too long, stalled.
cf. <xmqqqzkx9t95.fsf@gitster.g>
cf. <al6yCTDjBRn2HGq0@com-79390>
cf. <xmqqqzk2t7sm.fsf@gitster.g>
cf. <xmqq7blo4g7g.fsf@gitster.g>
source: <20260713-pks-libgit-in-subdir-v4-0-696240876eb1@pks.im>
* hs/rebase-continue-edit (2026-07-21) 1 commit
- rebase: add --[no-]edit to --continue
Support for skipping the editor when continuing a rebase after
conflict resolution has been added with the '--no-edit' option, and
forcing it with '--edit'. A new configuration variable
'rebase.noEdit' can be used to set the default behavior.
Waiting for response for too long, will discard.
cf. <xmqqldb4xlqa.fsf@gitster.g>
cf. <db7edc66-9b2a-47bc-98db-87d01885cef0@gmail.com>
source: <20260721140443.1809379-2-hugo@hsal.es>
* sn/rebase-update-refs-symrefs (2026-07-22) 2 commits
- rebase: guard non-branch symref targets
- rebase: skip branch symref aliases
'git rebase --update-refs' has been taught to resolve local branch
symrefs to their referents before queuing updates, ensuring aliases of
the current branch are skipped and duplicate updates are avoided to
prevent failures when branch aliases are present.
Waiting for response for too long, will discard.
cf. <1eba5fb2-ab76-41e9-955d-e283256ad25d@gmail.com>
cf. <98682fa4-55d9-4829-97f1-02e244b35266@gmail.com>
source: <pull.2126.v3.git.1784708107.gitgitgadget@gmail.com>
* tb/pack-with-duplicates (2026-07-24) 5 commits
- pack-bitmap: handle duplicate pack entries during MIDX reuse
- test-tool bitmap: reject packs with duplicate objects
- midx: verify duplicate pack entries by OID and offset
- packfile: recover delta cycles through duplicate entries
- t5308: test reverse indexes with duplicate objects
The handling of packfiles with duplicate object entries has been
hardened. Specifically, reverse index lookup, delta cycle
recovery, multi-pack-index verification, and pack reuse paths have
been updated to correctly handle or gracefully reject duplicate
entries.
Waiting for response for too long, will discard.
cf. <xmqqecgs3vg6.fsf@gitster.g>
source: <cover.1784927134.git.ttaylorr@openai.com>
* cl/regexec-macos-leak (2026-07-28) 2 commits
- SQUASH???
- regexec: work around macOS TRE leak on invalid UTF-8
A compatibility workaround has been introduced for macOS to address
a memory leak in the system regex engine when it encounters invalid
multibyte sequences. The workaround segments the input buffer at
invalid byte boundaries and searches each valid segment separately
using regexec(), avoiding the leaking path.
Waiting for response for too long, will discard.
cf. <xmqqse52bpa9.fsf@gitster.g>
cf. <anL7qL2-4h8ZlLcg@pks.im>
source: <20260728052538.12429-1-chungmin@chungminlee.com>
--------------------------------------------------
[Cooking]
* cc/lazy-fetch-trusted-bit (2026-08-13) 5 commits
- builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo
- upload-pack: read uploadpack.lazyFetchTrusted
- setup: add 'allow_dot' arg to path_allowlist_apply()
- setup: extract path_allowlist_apply()
- promisor-remote: factor out lazy_fetch_objects()
A new 'uploadpack.lazyFetchTrusted' configuration variable has been
introduced to allow 'upload-pack' to lazily fetch missing objects from
configured promisor remotes when serving trusted repositories.
Expecting a reroll.
cf. <CAP8UFD0iAvN2=j_15xUWiWuRMSJpBcS6WiYvOaB=wbdsdJyZ7w@mail.gmail.com>
source: <20260813154748.2378747-1-christian.couder@gmail.com>
* jk/rev-info-argv-to-free (2026-08-31) 2 commits
(merged to 'next' on 2026-09-04 at 9826377f2b)
+ revision: simplify mark_argv_for_free() callers
+ revision: hang on to "freed" argv elements
The memory ownership of argv elements passed to the revision
machinery has been made more robust by keeping logically "freed"
elements alive until the rev_info struct is released, preventing
use-after-free bugs when options store references to them.
Will merge to 'master'.
cf. <apaSDqIEyc82Q_zE@pks.im>
cf. <apayIuf9kXQcQPvS@pks.im>
cf. <xmqq8q5ksvd8.fsf@gitster.g>
source: <20260901062815.GC1075462@coredump.intra.peff.net>
* ps/ci-depends-on-ruby (2026-09-01) 1 commit
- ci: fix missing Ruby dependency in "documentation" job
The CI job that builds the documentation failed because it lacked
the 'gem' command. The 'asciidoc' package apparently stopped pulling
in the 'ruby' package as a transitive dependency. The CI script has
been updated to explicitly install 'ruby'.
Will merge to 'next'?
cf. <87pkyxwf9b.fsf@emacs.iotcl.com>
source: <20260901-b4-pks-ci-fix-documentation-job-v1-1-a8257ee2a9a4@pks.im>
* ps/odb-stop-registering-in-memory-sources (2026-09-02) 13 commits
- odb: remove the ability to link sources ad-hoc
- t/helper: stop registering alternates in "ref-store" command
- t/helper: adapt read-midx to not link ad-hoc source anymore
- builtin/multi-pack-index: refuse unknown sources with "--object-dir="
- odb/packed: fix memory leaks when freeing source
- tmp-objdir: drop unused function to register alternate
- odb: remove infrastructure to register submodule sources
- builtin/grep: stop registering submodule ODB as source
- submodule-config: stop registering submodule sources
- submodule-config: stop using `the_hash_algo`
- submodule-config: remove uses of `the_repository`
- cache-tree: remove dependency on `the_repository`
- cache-tree: drop `the_repository` in `cache_tree_fully_valid()`
- Merge branch 'ty/repository-fetch-if-missing' into ps/ps/odb-stop-registering-in-memory-sources
The mechanism to register in-memory alternate object sources has
been removed, as submodule object databases are now accessed
natively via their own repository structures. This simplifies
object database management and prepares the codebase for migrating
alternate tracking into the files backend.
Needs review.
source: <20260902-pks-odb-registering-in-memory-sources-v2-0-c6ca12fdea4d@pks.im>
* jk/ci-use-system-asciidoctor (2026-09-02) 2 commits
- ci: drop ALREADY_HAVE_ASCIIDOCTOR variable
- ci: fix missing Ruby dependency in "documentation" job
The CI script to install dependencies for the documentation build
has been updated to install asciidoctor directly via the system
package manager instead of pinning to an older version via gem.
Additionally, an obsolete variable used for retired Azure Pipelines
environments has been removed.
Will merge to 'next'?
cf. <apfWhYF6nmcFGKE3@pks.im>
cf. <apfzihj-1YAhn5lT@pks.im>
source: <20260902071409.GA641414@coredump.intra.peff.net>
* jk/submodule-error-leak (2026-09-01) 2 commits
- submodule--helper: free URL when repository setup fails
- repository: make repo_clear() idempotent
The error path in 'git submodule--helper' has been updated to plug a
memory leak when a repository handle could not be obtained,
leveraging an updated idempotent repo_clear().
Will merge to 'next'?
cf. <apfoO5br4MMZv7nR@pks.im>
source: <20260902055117.GA41587@coredump.intra.peff.net>
* sa/rev-list-missing-only (2026-09-03) 1 commit
- rev-list: add --missing-only option to filter output
The git rev-list command has been augmented with a '--missing-only'
option that filters the output to only show missing objects,
stripping the leading '?' character and suppressing present objects,
which is useful when used in combination with '--missing=print' or
'--missing=print-info'.
Will merge to 'next'?
source: <20260903204551.65592-2-siddharthasthana31@gmail.com>
* wf/imap-send-draft (2026-09-01) 1 commit
- imap-send: add --draft to set IMAP \Draft flag
The 'git imap-send' command has been taught to take the '--draft'
option to mark uploaded messages as drafts, which helps some email
clients render them properly for editing and sending.
Will merge to 'next'?
cf. <xmqq8q5kl4gq.fsf@gitster.g>
cf. <31d24dc3-3ef6-41cb-acbd-4cb4fb0d2338@app.fastmail.com>
source: <761c3f1b-e280-48b1-a2ad-770b68be3434@slotpi01m90>
* yt/pathspec-negative-prefix (2026-09-03) 2 commits
- dir: find common prefix among non-exclude pathspec items
- dir: do not apply prefix to negative pathspecs
- Merge branch 'jc/pathspec-match-const' into yt/pathspec-negative-prefix
(this branch uses jc/pathspec-match-const.)
The pathspec matching logic has been updated to avoid out-of-bounds
memory accesses when a negative pathspec is shorter than the common
prefix of positive pathspecs.
Waiting for response.
cf. <CABPp-BF6hps9DibSV4ghbowkOD-NfEsHYFdLoKab0hCfEi9rgw@mail.gmail.com>
cf. <CABPp-BFJo80oE=rtWc0FRNUxVh=6NHZeQmHD2q69VGwDcrHNhw@mail.gmail.com>
cf. <xmqqmrtx6qsk.fsf@gitster.g>
source: <887D6D84-F76E-4DCB-9633-CD78DA02BCC5@ytausch.de>
* cc/early-scan-options (2026-09-02) 6 commits
- fast-import: use early_scan_options() for --allow-unsafe-features
- parse-options: build early scan options from a struct option array
- parse-options: add parse_options_takes_argument()
- rev-parse: fix "--" detection when it is an option value
- bisect: fix "--" detection when a term name is "--"
- parse-options: add early_scan_options()
The process of parsing command-line options in commands that
perform an early scan over their arguments (such as 'git bisect',
'git rev-parse', and 'git fast-import') has been unified using a
new early-scan sub-API, which parses and skips known options taking
separate values to prevent logic bugs.
Waiting for response.
cf. <xmqqpkyviizc.fsf@gitster.g>
source: <20260902161047.476753-1-christian.couder@gmail.com>
* ec/commit-fixup-options (2026-05-26) 2 commits
- commit: allow -c/-C for all kinds of --fixup
- commit: allow -m/-F for all kinds of --fixup
Support for '-m', '-F', '-c', or '-C' options to supply a commit log
message from outside the editor has been added for all 'git commit
--fixup' variations.
Expecting a reroll.
cf. <CA+JQ7M__GOnM9LHt0txry-G2z2CKhdZr0b-rU=Yd_A0gCEwmaQ@mail.gmail.com>
source: <cover.1779792311.git.erik@cervined.in>
* tc/replay-linearize (2026-08-31) 3 commits
(merged to 'next' on 2026-09-04 at 92ae794bfc)
+ replay: offer an option to linearize the commit topology
+ replay: resolve the replay base outside pick_regular_commit()
+ replay: add helper to put entry into replayed_commits
The 'git replay' command has been taught the '--linearize' option to
drop merge commits and linearize the replayed history, mimicking 'git
rebase --no-rebase-merges'.
Will merge to 'master'.
cf. <CABPp-BF1=DZAxX5Now4pCKPi8=cpXo506z=8QVu2vYCSiKdqMA@mail.gmail.com>
source: <20260831-toon-git-replay-drop-merges-v9-0-61c4232c6f36@iotcl.com>
* jc/checkout-refactor (2026-08-30) 8 commits
- checkout: move post_checkout_hook() to checkout.c
- checkout: wrap overly long lines
- checkout: restructure switch, restore, and checkout entrypoints
- checkout: extract branch setup and tracking helpers
- checkout: extract option validation and pathspec helpers
- checkout: validate stage and merge option compatibility in checkout_paths()
- checkout: validate new branch name in checkout_branch()
- checkout: pass cb_option explicitly to branch name parsers
The front-end code for 'git checkout', 'git switch', and 'git
restore' has been restructured to cleanly separate their pathspec
and branch handling, eliminating a common bottleneck and paving the
way to libify utility helpers.
Waiting for response.
cf. <xmqqo6el1xz0.fsf@gitster.g>
cf. <xmqqse3x1y20.fsf@gitster.g>
source: <20260830204835.1040408-1-gitster@pobox.com>
* hk/typofix (2026-08-31) 1 commit
(merged to 'next' on 2026-09-03 at d33f0c0813)
+ versioncmp: fix typo in versioncmp.c, t/t0022-crlf-rename.sh
Various spelling mistakes in comments and test descriptions have
been corrected.
Will merge to 'master'.
source: <20260901-typo-fix-v3-1-cc342f329190@gmail.com>
* ll/doc-pushcert-if-asked (2026-08-29) 1 commit
- doc: remote-helpers: option pushcert if-asked
he remote helper documentation for the 'pushcert' option has been
updated to mention that it can also take 'if-asked', reflecting the
existing implementation in the code.
Needs review.
source: <20260829183659.29947-1-lorenz.leutgeb@posteo.eu>
* jc/you-still-use-that (2026-08-27) 1 commit
(merged to 'next' on 2026-08-30 at d8f3941368)
+ you_still_use_that(): reword the instructions
The instructions for deprecated commands emitted by
you_still_use_that() have been reworded to clarify that the removal
decision is final and to provide more assertive guidance on finding
a replacement.
Will merge to 'master'.
source: <xmqqse3z8m5g.fsf_-_@gitster.g>
* ws/squelch-svn-migrate (2026-08-27) 2 commits
- Makefile: add NO_GIT_SVN knob to skip building/installing git-svn
- git-svn: don't print v1-layout migration noise when there's nothing to migrate
Needs review.
source: <20260827234345.1037130-1-wesleys@opperschaap.net>
* dw/config-read-both-global (2026-08-23) 3 commits
- config: read global scope via config_sequence
- config: let sequence require a successful file
- path: use forward slashes in XDG config on Windows
The git config --global read operations have been updated to respect
both $HOME/.gitconfig and $XDG_CONFIG_HOME/git/config, fixing an
inconsistency where only the former was read when both configuration
files are present.
Waiting for response.
cf. <xmqqo6esti9o.fsf@gitster.g>
cf. <xmqqecfkhify.fsf@gitster.g>
cf. <xmqqy0dsg2vt.fsf@gitster.g>
cf. <xmqqse40g22c.fsf@gitster.g>
source: <20260823-fix-config-list-global-home-and-xdg-v2-0-b29cc63f017b@microsoft.com>
* vv/branch-recurse-no-start-ref (2026-08-21) 2 commits
- branch: allow recursion with no tracking name
- branch: do not track a start point with no ref
The --recurse-submodules option in 'git branch' has been fixed to
avoid a crash when the start point is not a reference (e.g., a raw
object ID). The creation path now skips setting up tracking and
properly forwards the absent tracking name to the submodule helper.
Needs review.
source: <20260822-vv-branch-recurse-no-start-ref-v1-0-46dc140acaa8@zitro.id>
* kn/reftable-optimize-reloading (2026-08-24) 4 commits
(merged to 'next' on 2026-08-28 at d714ed570a)
+ reftable/stack: avoid reloading the stack when already locked
+ reftable/stack: move list lock to `struct reftable_stack`
+ reftable/stack: rename reftable_stack_new_addition()
+ reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`
The reftable code has been optimized to avoid an unnecessary
stat/reload of the stack when an addition already holds the
list_file lock, reducing the number of newfstatat syscalls from
linear to constant when writing refs.
Will merge to 'master'.
cf. <ao1uqpCxFHlOyTV-@pks.im>
cf. <20260824225202.GA190620@coredump.intra.peff.net>
source: <20260824-740-optimize-reloading-the-reftable-stack-v2-0-9c9de2eb0af7@gmail.com>
* ps/odb-alternates-at-creation (2026-08-31) 8 commits
- odb/source: remove the ability to write alternates
- builtin/clone: write alternates via `odb_create_on_disk()`
- odb/source: support writing alternates when creating the database
- builtin/clone: move setup of alternates for non-shared local clones
- builtin/clone: move setup of alternates for shared local clones
- builtin/clone: refactor handling of "--reference{,-if-able}"
- builtin/clone: move around `setup_reference()`
- builtin/clone: defer setup of the object database
- Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-alternates-at-creation
The setup of alternates has been deferred to object database
creation time during clone, which drops the unused ad-hoc alternate
writing API, simplifying the object database backend interface.
Needs review.
source: <20260831-pks-odb-write-alternates-at-creation-time-v2-0-aecd2382ba1c@pks.im>
* ps/odb-pluggable-fsck (2026-08-30) 10 commits
- builtin/fsck: move loose object verification into the loose source
- builtin/fsck: move multi-pack index verification into the packed source
- builtin/fsck: move bitmap verification into the packed source
- builtin/fsck: move reverse index verification into the packed source
- builtin/fsck: move packfile verification into the packed source
- odb: provide infrastructure for pluggable fsck checks
- builtin/fsck: don't check alternates with "--no-full"
- builtin/fsck: de-globalize option handling
- builtin/fsck: merge `fsck_obj_buffer()` and `fsck_obj()`
- builtin/fsck: use `fsck_obj_buffer()` when checking loose objects
- Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-pluggable-fsck
- Merge branch 'ps/odb-pluggable-pack-generation' into ps/odb-pluggable-fsck
The consistency checks for the object database (fsck) have been
decoupled from the generic builtin implementation and moved into the
backend-specific object source layers, making them pluggable for
different object storage formats.
Needs review.
cf. <CAOLa=ZSi1TiTZ=i=SQp+pmjTOm2_wY-NiCotx66+M6VDKx=ZXg@mail.gmail.com>
source: <20260831-pks-odb-source-fsck-v2-0-f9b16ef4957b@pks.im>
* rs/worktree-add-basename-fixes (2026-08-25) 4 commits
(merged to 'next' on 2026-09-03 at b04ceb887c)
+ worktree add: let worktree_basename() return string copy
+ worktree add: trim slashes when deriving branch name from path
+ worktree add: reject separator-only path
+ worktree add: don't read out of bounds in worktree_basename()
The string extraction logic for the branch name and worktree name
from the given path in 'git worktree add' has been corrected and
simplified to avoid out-of-bounds reads and improper handling of
trailing slashes.
Will merge to 'master'.
cf. <xmqqfqzuw23a.fsf@gitster.g>
source: <20260825180350.2099-1-l.s.r@web.de>
* en/no-amend-during-conflicts (2026-09-01) 5 commits
- commit: refuse partial commits during conflict resolution
- commit: refuse to amend during conflict resolution
- commit: reword the empty-commit rebase amend error
- commit: allow a partial commit when a rebase pick becomes empty
- commit: clarify FROM_REBASE_PICK and is_from_rebase() names
Teach 'am', 'revert', and 'rebase' that running 'commit --amend' or a
partial 'commit <paths>' makes no sense during operations that stop
and return control to the user to resolve conflicts left in the
working tree, just like 'cherry-pick' and 'merge' do.
Will merge to 'next'?
cf. <1c3f07e0-63c0-483d-8e46-e4edbdd6991a@gmail.com>
cf. <4ed77ebd-e4ba-4d37-9c92-d987b70135a6@gmail.com>
cf. <xmqqqzji5id2.fsf@gitster.g>
source: <pull.2389.v4.git.git.1788301481.gitgitgadget@gmail.com>
* as/utimensat-utimes (2026-08-21) 3 commits
- compat/posix: drop legacy <utime.h> header and shims
- treewide: use utimensat(2) instead of legacy utime(3p)
- compat/posix: introduce utimensat(2) wrapper
The codebase has been updated to use the newer utimensat() POSIX
function instead of the obsolescent utime(), allowing
high-precision timestamps while preserving fallback compatibility.
Waiting for response.
cf. <aonIVn-ZQoMKWCAd@fruit.crustytoothpaste.net>
source: <pull.2209.git.1787322203.gitgitgadget@gmail.com>
* kn/receive-report-hook (2026-09-04) 4 commits
- hook: introduce the receive-report hook
- receive-pack: move message generation to separate function
- receive-pack: drop static variables to track report status version
- doc: add proc-receive hook info in 'git-receive-pack.adoc'
A new hook 'report' is added to 'git receive-pack', which runs after
reference updates and allows the server to filter or modify the
packet-line status report sent back to the client.
Needs review.
source: <20260904-758-introduce-hook-v7-0-6c66f0a3a572@gmail.com>
* en/midx-missing-pack-fallback (2026-08-29) 4 commits
(merged to 'next' on 2026-09-04 at 73a4cd73de)
+ packfile: recover when a multi-pack-index names a removed pack
+ mktree: do not use OBJECT_INFO_QUICK when checking objects
+ mktree: plug per-tree leak in --batch mode
+ replay: fail gracefully when a merge input is unreadable
+ Merge branch 'ps/odb-generic-corrupt-objects' into en/midx-missing-pack-fallback
The object lookup machinery has been taught to gracefully recover
when a multi-pack-index points to an owning pack that was removed
during a concurrent geometric repack, and 'git replay' has been
fixed to not segfault when reading such missing objects.
Will merge to 'master'.
cf. <20260831231005.GA973618@coredump.intra.peff.net>
cf. <374bffe1-47ff-4cb6-9d69-f4b7da7292da@gmail.com>
source: <pull.2207.v3.git.1787986831.gitgitgadget@gmail.com>
* ll/zsh-complete-git-potty-options (2026-08-19) 1 commit
(merged to 'next' on 2026-08-31 at fee97cc13c)
+ completion: zsh: support completion after "git -C <path>"
The zsh completion script (in 'contrib/') has been updated to
correctly locate the Git command after global options like '-C' by
properly skipping them, similar to how the bash completion does.
Will merge to 'master'.
cf. <CALnO6CC35iuyJpKZtkEN7fGuGK7zKd_jbebyZdKSQ1pyfOBRZA@mail.gmail.com>
cf. <xmqqld9sczd0.fsf@gitster.g>
source: <pull.2155.v2.git.1787144872870.gitgitgadget@gmail.com>
* ap/http-preserve-wwwauth-redirect (2026-08-19) 1 commit
- http: preserve wwwauth_headers across redirects
When an HTTP request triggers a redirect and the target yields an
authentication challenge, the WWW-Authenticate headers received
during the redirect are now explicitly preserved across the
credential URL update, fixing an issue where they were incorrectly
cleared.
Needs review.
source: <20260819-http-preserve-wwwauth-redirect-v2-1-4c61039432b0@nvidia.com>
* kh/doc-datamodel (2026-08-23) 4 commits
- doc: datamodel: link to the glossary
- doc: glossary: link four of the terms to gitdatamodel(7)
- doc: git: link to the gitdatamodel(7) tutorial
- doc: git: list gitdatamodel(7) as a concept guide
The gitdatamodel documentation page has been linked from a handful
of key documentaiton pages.
Will merge to 'next'?
cf. <apUrC_ROf9lyiuAm@pks.im>
cf. <954865cf-5984-4e0d-9e8c-7c874896a1f2@app.fastmail.com>
source: <V2_CV_doc_datamodel_advertize.c20@msgid.xyz>
* yn/worktree-repair-relative (2026-08-28) 1 commit
(merged to 'next' on 2026-08-31 at 15072b025f)
+ worktree repair: detect relative path in .git file correctly
The git worktree repair command failed to rewrite the .git file of
a working tree from a relative path to an absolute path when the
command was run in the working tree itself. The
read_gitfile_gently() function was modified to also return whether
the path originally recorded in the file was absolute, and this new
capability is used to correctly detect such mismatches.
Will merge to 'master'.
cf. <xmqqh5ke3zxt.fsf@gitster.g>
source: <pull.2205.v4.git.1787930386252.gitgitgadget@gmail.com>
* kh/format-rev-more-options (2026-08-18) 5 commits
- format-rev: learn --abbrev, --color, and --date
- doc: rev-list-options.adoc: factor out --date alts
- format-rev: factor option variables into a struct
- format-rev: place BUG calls first in callback
- format-rev: use lower case for opts description
The experimental 'git format-rev' has been taught a few more
formatting options.
Needs review.
source: <V2_CV_format-rev_three_more_opts.bd3@msgid.xyz>
* ns/ref-symref-additional-tests (2026-08-20) 2 commits
(merged to 'next' on 2026-09-03 at 67a1cf3baa)
+ t1402: test forbidden characters in refnames
+ t1401: check symbolic-ref failure and --quiet silence on a non-symbolic ref
A few tests for the reference handling subsystem have been added to
exercise the handling of forbidden characters and symbolic references.
Will merge to 'master'.
cf. <apUdDyG98D5upbhj@pks.im>
source: <pull.2203.v2.git.1787264417682.gitgitgadget@gmail.com>
source: <pull.2204.v3.git.1787763107646.gitgitgadget@gmail.com>
* gg/http-ssl-verify-status (2026-08-18) 1 commit
- http: add http.sslVerifyStatus to check stapled OCSP responses
The HTTP transport has been taught to check the revocation status of
the server certificate using the stapled OCSP response during the
TLS handshake via a new 'http.sslVerifyStatus' configuration
variable.
Waiting for response.
cf. <xmqqecfez7ie.fsf@gitster.g>
source: <20260818214858.65122-1-ggordon@gitlab.com>
* ty/repo-config-cleanups (2026-08-07) 3 commits
- environment: remove inaccurate repo_config_values comments
- environment: clarify repository config getter documentation
- environment: drop redundant NULL checks in config getters
Repository configuration getters in 'environment.c' have been
simplified by removing redundant NULL checks. The documentation for
these getters in 'environment.h' has been clarified, and inaccurate
section comments inside 'struct repo_config_values' have been removed.
Needs review.
source: <20260807085932.3958759-1-cat@malon.dev>
* dk/use-nsec-runtime (2026-08-31) 3 commits
- core: convert build-time USE_NSEC into runtime core.useNanosec
- environment: align repo_config_values_init with struct declaration
- meson: expose knob for xmlto relative links in manuals
The build-time knob 'USE_NSEC' for nanosecond stat precision has been
converted to a runtime configuration 'core.useNanosec', allowing
distributions to bundle one binary that adapts to filesystem
capabilities dynamically.
Waiting for response.
cf. <xmqqbjaefhwo.fsf@gitster.g>
source: <cover.1788206466.git.ben.knoble@gmail.com>
* bc/restrict-hex-to-lowercase (2026-07-29) 6 commits
- hex: allow only lowercase object IDs in breaking changes mode
- object-name: use hexval
- hex: label usages of hex parsing for object IDs
- hex: make hex_to_bytes accept kind of hex to use
- hex: allow specifying hex type with hex2chr
- hex: add functionality for lowercase-only hex
The parser for hex object names has been updated to reject uppercase
hexadecimal characters when running in the breaking changes mode, in
preparation for Git 3.0.
Expecting a reroll.
cf. <ao4MJQgp6Ai4tJxi@fruit.crustytoothpaste.net>
cf. <ao4MqtDxZJaMEBBI@fruit.crustytoothpaste.net>
source: <20260729233215.398654-1-sandals@crustytoothpaste.net>
* js/mingw-build-updates (2026-08-12) 12 commits
- mingw: allow `git.exe` to be used instead of the "Git wrapper"
- mingw: ensure valid CTYPE
- mingw: always define `ETC_*` for MSYS2 environments
- windows: skip linking `git-<command>` for built-ins
- mingw: rely on MSYS2's metadata instead of hard-coding it
- mingw: only enable the MSYS2-specific stuff when compiling in MSYS2
- mingw: set the prefix and HOST_CPU as per MSYS2's settings
- mingw: avoid over-specifying `--pic-executable`
- mingw: only use -Wl,--large-address-aware for 32-bit builds
- mingw: drop the -D_USE_32BIT_TIME_T option
- mingw: stop hard-coding `CC = gcc`
- mingw: include the Python parts in the build
A collection of patches from Git for Windows has been upstreamed,
mostly focusing on simplifying and robustifying build configurations
for MinGW/MSYS2, dropping obsolete compatibility options, and allowing
the main 'git.exe' to be used directly without the extra wrapper
process on Windows.
Waiting for response.
cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org>
source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com>
* yn/worktree-ambiguous-remote-advice (2026-08-27) 4 commits
(merged to 'next' on 2026-08-30 at 8e7670286a)
+ worktree add: treat multiple matches with --guess-remote as an error
+ worktree add: improve message for ambiguous remote branch name
+ checkout: improve message for ambiguous remote branch name
+ checkout: extract function to display advice for ambiguous remotes
'git checkout' and 'git worktree add' makes guesses based on a name
of a remote-tracking branch, but does not give an error when such a
remote-tracking branch cannot be uniquely identified, which has
been corrected.
Will merge to 'master'.
cf. <xmqq4igfa2pv.fsf@gitster.g>
source: <pull.2197.v10.git.1787841717.gitgitgadget@gmail.com>
* hn/ci-cancel-stale-pr-runs (2026-08-31) 1 commit
(merged to 'next' on 2026-09-03 at e4d4816938)
+ ci: cancel stale pull request workflow runs
GitHub Actions CI workflow runs triggered by pull requests have
been configured to cancel older runs when a new push is made to the
same pull request.
Will merge to 'master'.
source: <pull.2369.v3.git.git.1788193095825.gitgitgadget@gmail.com>
* hn/checkout-m-autostash-refine (2026-09-03) 2 commits
- checkout: separate autostash conflict advice from branch-switch message
- stash: reserve exit status 1 for conflicts
The autostash fallback in 'git checkout -m' has been refined to only
retry when there are local changes. Additionally, a blank line now
visually separates autostash conflict advice from the subsequent
branch-switch message.
Will merge to 'next'?
cf. <xmqq7bl2b1zs.fsf@gitster.g>
source: <pull.2364.v5.git.git.1788446398.gitgitgadget@gmail.com>
* kj/repo-info-more-path-keys (2026-08-25) 7 commits
- repo: add path.cdup
- repo: add path.git-prefix
- repo: add path.grafts with absolute and relative suffixes
- repo: add path.index with absolute and relative suffixes
- repo: add path.hooks with absolute and relative suffixes
- repo: add path.superproject-root with absolute and relative suffixes
- repo: add path.toplevel with absolute and relative suffix formatting
The 'git repo info' command has been taught more keys to output
paths of various repository components (such as the working tree
root, superproject working tree, object database, etc.), supporting
both absolute and relative path formats.
Needs review (Broken???)
cf. <CA+rGoLcZ6u+Rbz2PNGiaPbeHB=LSAqxi0r6jYZL3RjG6wimJ3Q@mail.gmail.com>
source: <20260825175818.645579-1-jayatheerthkulkarni2005@gmail.com>
* tc/last-modified-bloom (2026-09-01) 6 commits
- last-modified: keep per-path Bloom filters for wildcard pathspecs
- last-modified: check pathspec against Bloom filter first
- revision: add Bloom check that includes parent directories
- bloom: add helper to check if any key in a vector is present
- revision: expose check for paths maybe changed in Bloom filter
- revision: move bloom keyvec precondition into function
The 'git last-modified' command has been optimized by using Bloom
filters. It now reuses revision walk filtering logic from 'git log'
to pre-filter commits, and maintains per-path Bloom filters even when
wildcard pathspecs are used.
Needs review.
source: <20260901-toon-speed-up-last-modified-v4-0-a09949800404@iotcl.com>
* ds/trace2-tolerate-failed-timestamp (2026-08-31) 7 commits
- trace2: remove use of xcalloc()
- trace2: remove use of ALLOC_GROW()
- trace2: remove use of xstrfmt()
- trace2: remove use of ALLOC_ARRAY()
- trace2: remove use of xstrdup()
- trace2: tolerate failed timestamp formatting
- banned-die: create header for banning of functions
Functions like `xstrfmt()` and `xcalloc()` have been banned from use
in the trace2 API codebase to prevent calls to `die()` which lead to
unwanted process exits and recursion when memory allocation fails.
Needs review.
source: <pull.2178.v3.git.1788197143.gitgitgadget@gmail.com>
* pz/fetch-submodule-errors-config (2026-07-16) 2 commits
- fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal
- submodule: fix premature failure in recursive submodule fetch
The 'git fetch' command can now configure how submodule fetch errors
are handled via 'fetch.submoduleErrors' and '--submodule-errors',
making them non-fatal. A premature failure during recursive submodule
fetches has been fixed by deferring the error until the OID-based
retry phase fails.
Needs review.
source: <20260716140956.1023740-1-paulius.zaleckas@gmail.com>
* gr/add-e-use-apply-api (2026-07-10) 1 commit
(merged to 'next' on 2026-08-31 at 04ee2ac5c5)
+ builtin/add.c: replace run_command() with direct apply_all_patches() call
The application of the edited patch in 'git add -e' has been
refactored to use the internal apply API directly, avoiding the need
to spawn a 'git apply' subprocess.
Will merge to 'master'.
cf. <xmqqbjaoiyzx.fsf@gitster.g>
source: <20260711061246.58079-1-gatlavishweshwarreddy26@gmail.com>
* fz/rebase-autosquash-empty (2026-08-27) 1 commit
- sequencer: honor --empty when a fixup!/squash! empties its target
A commit that is emptied by melding a 'fixup!' or 'squash!' commit
during 'git rebase --autosquash' is now handled according to the
'--empty' option, allowing it to be dropped, kept, or to halt the
rebase.
Waiting for response.
cf. <511300fe-112d-4f20-bd3f-e401e68c4a27@gmail.com>
source: <20260827-fz-autosquash-empty-v4-1-f98ffd575780@gmail.com>
* mm/lib-httpd-cgi-safe (2026-09-01) 3 commits
- t/lib-httpd: document writing concurrency-safe CGI helpers
- t/lib-httpd: make http-429 first-request check atomic
- t/lib-httpd: fix apply-one-time-script race under concurrent requests
CGI helper scripts used by HTTP-related test scripts have been updated
to use atomic filesystem operations, preventing race conditions when
Apache handles concurrent requests.
Will merge to 'next'?
cf. <apkFyvN4hcEOadQq@pks.im>
source: <pull.2171.v5.git.1788277983.gitgitgadget@gmail.com>
* ij/subtree-reject-v2-config (2026-07-06) 2 commits
- git-subtree: Bail out if we find output from Rust rewrite (test)
- git-subtree: Bail out if we find output from Rust rewrite
The shell script implementation of 'git subtree' has been updated to
check for the presence of the configuration file of the new Rust
implementation, preventing users from accidentally running the old
script on repositories already managed by the new tool.
Expecting a reroll.
cf. <27219.20156.438730.881821@chiark.greenend.org.uk>
source: <20260706115816.20267-1-ijackson@chiark.greenend.org.uk>
* mm/line-log-limited-ops (2026-09-02) 7 commits
- diffcore-pickaxe: limit -G to the -L tracked range
- diff: support --check with -L line ranges
- diff: support stat formats with -L
- diff: extract a line-range diff helper for reuse
- diff: emit -L hunk headers via xdiff's formatter
- diff: simplify the line-range filter by classifying removals immediately
- diff: rename line-range filter struct and clarify fields
(this branch is used by mm/diff-process-hunks.)
The 'git log -L<range>:<path>' command has been taught to limit
various 'diff' operations, such as '--stat', '--check', and '-G', to
the specified range and path.
Needs review.
source: <pull.2152.v3.git.1788411919.gitgitgadget@gmail.com>
* hn/history-squash (2026-08-20) 8 commits
- history: support editing squashed commit messages
- history: create squashed commits without editing
- history: protect branches when squashing a range
- history: validate squash revision ranges
- history: add skeleton for squash subcommand
- sequencer: share the squash message marker helpers and flags
- history: give commit_tree_ext a message template
- history: extract helper for a commit's parent tree
The experimental 'git history' command has been taught a new 'squash'
subcommand to fold a range of commits into a single commit, with any
descendants replayed on top.
Waiting for response.
cf. <xmqq4igov9h9.fsf@gitster.g>
source: <pull.2337.v14.git.git.1787249432.gitgitgadget@gmail.com>
* tb/midx-incremental-custom-base (2026-06-12) 3 commits
- midx-write: include packs above custom incremental base
- midx: pass custom '--base' through incremental writes
- t5334: expose shared `nth_line()` helper
The 'git multi-pack-index write --incremental' command has been
corrected to properly honor the '--base' option. Previously, the
custom base was ignored by the normal write path; packs from layers
above the selected base were incorrectly skipped by the pack exclusion
logic, and reachability closure for bitmaps was broken.
Expecting a reroll.
cf. <an4uIQA09rDCwwBp@com-79390>
cf. <apUbQ4S-zJGtBeu2@pks.im>
source: <cover.1781294771.git.me@ttaylorr.com>
* mm/diff-process-hunks (2026-08-13) 11 commits
- fixup! diff: consult oid-only hunk providers via diff.<driver>.process
- diff: consult oid-only hunk providers via diff.<driver>.process
- userdiff: add diff.<driver>.process config
- sub-process: add a gentle status read
- sub-process: separate process lifecycle from hashmap management
- blame: read precomputed hunks
- diff: read precomputed hunks for stat output
- diff: record precomputed hunks during stat output
- diff-hunks: add the store format, library, and command
- diff: introduce a hunk provider interface
- gitattributes: document how external diff drivers relate to diff features
- Merge branch 'mm/line-log-limited-ops' into mm/diff-process-hunks
(this branch uses mm/line-log-limited-ops.)
A new 'diff.<driver>.process' configuration has been introduced to
allow a long-running external process to act as a hunk provider,
enabling external tools to control which lines Git considers changed
while leaving all output formatting (word diff, color, blame, etc.) to
Git's standard pipeline.
Expecting a reroll.
cf. <CAC2Qwm+kzT_3_GKrpay=JLGYsxS10oWCg2MJPHrCVogFHA0OdA@mail.gmail.com>
source: <20260801174156.2998808-1-mmontalbo@gmail.com>
--------------------------------------------------
[Discarded]
* ps/fetch-packfile-uris-parallel (2026-08-21) 2 commits
. fetch-pack: allow parallelizing packfile URI fetches
. fetch-pack: prepare for threaded fetching of packfile URIs
The `git fetch` and `git clone` commands have been optimized to
download packfile URIs in parallel when the new
`fetch.packfileURIThreads` configuration is set, significantly
speeding up fetches from servers that advertise multiple packfiles.
Retracted for now.
cf. <apa2XPxAFyUXveJY@pks.im>
source: <20260821-pks-parallelize-fetching-packfile-uris-v1-0-0df52d9427ce@pks.im>
* kh/format-patch-range-diff-notes (2026-08-24) 3 commits
. format-patch: learn --[no-]range-diff-notes
. revision.h: rename struct member to reflect notes role
. format-patch: simplify get_notes_arg parameters
The 'format-patch' command has been updated with options to
configure notes specifically for range-diff output, allowing them to
differ from the notes displayed on the patches themselves.
Retracted.
cf. <9335a35f-e9c0-4e62-812c-e5855c201003@app.fastmail.com>
source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
* jc/die-for-incompatible-opts (2026-08-27) 1 commit
. die_for_incompatible_opts(): unbounded number of options
The die_for_incompatible_opt[234]() family of functions has been
generalized to handle an arbitrary number of mutually exclusive
options via a variadic function.
Retracted.
cf. <xmqqfqzv1g6z.fsf@gitster.g>
source: <xmqqbjana2wv.fsf@gitster.g>
* zy/apply-abandoned-header-fix (2026-07-01) 1 commit
. apply: avoid leaking abandoned git-header state
A candidate 'git diff' header parsed by 'git apply' has been isolated
in a temporary structure, preventing any partially parsed state from
polluting the main patch structure and causing assertions to trip if
the header is ultimately rejected.
Discarded.
cf. <xmqqtsogei9d.fsf@gitster.g>
source: <20260702041759.51572-1-zhihao.yao@njit.edu>
^ permalink raw reply [flat|nested] 21+ messages in thread* kh/format-patch-range-diff-notes
2026-09-04 23:55 What's cooking in git.git (Sep 2026, #02) Junio C Hamano
@ 2026-09-05 6:31 ` Kristoffer Haugsbakk
0 siblings, 0 replies; 21+ messages in thread
From: Kristoffer Haugsbakk @ 2026-09-05 6:31 UTC (permalink / raw)
To: Junio C Hamano, git
On Sat, Sep 5, 2026, at 01:55, Junio C Hamano wrote:
> * kh/format-patch-range-diff-notes (2026-08-24) 3 commits
> . format-patch: learn --[no-]range-diff-notes
> . revision.h: rename struct member to reflect notes role
> . format-patch: simplify get_notes_arg parameters
>
> The 'format-patch' command has been updated with options to
> configure notes specifically for range-diff output, allowing them to
> differ from the notes displayed on the patches themselves.
>
> Retracted.
> cf. <9335a35f-e9c0-4e62-812c-e5855c201003@app.fastmail.com>
> source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
I will make a draft update of the doc that wasn’t clear. Then we’ll see
if an unretraction and new version makes sense.
^ permalink raw reply [flat|nested] 21+ messages in thread
* What's cooking in git.git (Aug 2026, #11)
@ 2026-08-26 23:21 Junio C Hamano
2026-08-27 6:06 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
0 siblings, 1 reply; 21+ messages in thread
From: Junio C Hamano @ 2026-08-26 23:21 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and is a candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all. They may be annotated with a URL
to a message that raises issues but they are by no means exhaustive.
A topic without enough support may be discarded after a long period
of no activity (of course, it can be resubmitted when new interest
arises).
The 19th batch of topics have now graduated to the 'master' branch.
We have 563 non-merge commits in 'master' since Git 2.55. There
are 75 non-merge commits cooking in 'next' (note that some have
been reverted), and 209 non-merge commits, including those in and
out of 'next', in 'seen' as of this writing.
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* cc/fast-import-usage (2026-08-11) 12 commits
(merged to 'next' on 2026-08-15 at a0434930b4)
+ fast-import: remove useless from_stream argument
+ fast-import: use parse_options() for command line options
+ fast-import: use callbacks to parse some options
+ fast-import: use struct option for usage string
+ fast-import: move command state globals into 'struct fast_import_state'
+ fast-import: introduce 'struct fast_import_state'
+ fast-import: factor out option_*() functions
+ fast-import: use int for some bool flags
+ fast-import: localize 'i' into the 'for' loops using it
+ api-parse-options.adoc: document hidden and OPT_*_F option macros
+ api-parse-options.adoc: document per-option flags
+ parse-options: introduce OPT_HIDDEN_GROUP
The usage string of 'git fast-import' has been updated to use the
parse_options() API for displaying help, and its SYNOPSIS in the
documentation has been standardized to match.
Graduated to 'master'.
cf. <CABPp-BE_gVtCF+Y0AAyXSXnJ2hUK0pJiWqEhkD8kVc4S8-y7kQ@mail.gmail.com>
source: <20260811083314.2023489-1-christian.couder@gmail.com>
* cc/git-shallow-file-wo-value (2026-08-11) 1 commit
(merged to 'next' on 2026-08-17 at f6a6ff92a6)
+ git: avoid segfault on "git --shallow-file" without a value
The '--shallow-file' option of 'git' command requires a value, but the
code did not check the presence of a value and instead segfaulted
without one, which has been corrected.
Graduated to 'master'.
cf. <an10XhFPo0nJWJIV@pks.im>
cf. <xmqqcxvo1n8w.fsf@gitster.g>
source: <20260811121446.2080190-1-christian.couder@gmail.com>
* ch/chdir-notify-drop-name (2026-08-14) 1 commit
(merged to 'next' on 2026-08-18 at 973cefddd7)
+ chdir-notify.h: Removed unused param 'name'
The unused name parameter in 'struct chdir_notify_entry' has been
removed from chdir_notify_register(), chdir_notify_unregister(), and
related callback signatures across several subsystems, simplifying the
API now that trace output no longer uses it.
Graduated to 'master'.
cf. <20260815051213.GA26013@coredump.intra.peff.net>
source: <20260814214210.1625-1-colinlewishinton@gmail.com>
* en/diff-l-opt-help (2026-08-13) 1 commit
(merged to 'next' on 2026-08-17 at 4b6b3295ed)
+ diff: avoid misleading statement about -l option
The help text for the '-l' option of 'git diff' has been updated.
Graduated to 'master'.
cf. <xmqqbjb4rd5q.fsf@gitster.g>
source: <pull.2035.v2.git.1786673186855.gitgitgadget@gmail.com>
* en/sequencer-lose-pretty-given (2026-08-11) 1 commit
(merged to 'next' on 2026-08-17 at 82d0706aef)
+ sequencer: remove unnecessary variable setting
The setting of a now-unused member '.pretty_given' in the sequencer
machinery has been removed.
Graduated to 'master'.
cf. <an11zsTm-fanH8yt@pks.im>
cf. <xmqqa4qrxneq.fsf@gitster.g>
source: <pull.1922.git.1786516959130.gitgitgadget@gmail.com>
* en/serve-promisor-remote-fix (2026-08-11) 1 commit
(merged to 'next' on 2026-08-17 at a4d7a9d1d6)
+ serve: reject valueless promisor-remote capability
A client requesting the promisor-remote capability without a value
caused a null pointer dereference, which has been corrected by
rejecting a request without an argument.
Graduated to 'master'.
cf. <CAP8UFD0+iXC3VxWmuuuB7La-pP6hdz58tr6vaEJSKpXJ_4ZH2w@mail.gmail.com>
source: <pull.2199.git.1786516783909.gitgitgadget@gmail.com>
* hn/send-email-missing-subject-error (2026-08-10) 1 commit
(merged to 'next' on 2026-08-15 at 6470901400)
+ send-email: clarify missing subject error
The error message given by 'git send-email' when a message file is
missing a 'Subject:' header has been clarified, and the error string
is now terminated with a newline so that Perl avoids appending its
internal source location data.
Graduated to 'master'.
cf. <xmqqtsp165tj.fsf@gitster.g>
source: <pull.2375.v2.git.git.1786384412423.gitgitgadget@gmail.com>
* jc/complete-checkout (2026-08-13) 4 commits
(merged to 'next' on 2026-08-19 at 758fc8c411)
+ completion: 'git checkout' completes untracked paths as a last resort
+ completion: complete tracked paths for "git checkout"
+ completion: no-op refactoring of checkout completion
+ Merge branch 'jc/complete-diff-tracked-paths' into jc/complete-checkout
(this branch uses jc/complete-diff-tracked-paths.)
'git -C <dir> checkout fi<TAB>' did not complete, which has been
corrected.
Graduated to 'master'.
cf. <CABPp-BFeLStBR3OeTCJoBmC7cn_VXrn4RcvBg-WWGyz4LpJxsg@mail.gmail.com>
source: <20260813191234.1066662-1-gitster@pobox.com>
* jc/complete-diff-tracked-paths (2026-08-12) 3 commits
(merged to 'next' on 2026-08-19 at 37263f6528)
+ completion: 'git diff' completes untracked paths as a last resort
+ completion: complete tracked paths for 'git diff'
+ completion: no-op refactoring of diff completion
(this branch is used by jc/complete-checkout.)
'git -C <dir> diff fi<TAB>' did not complete 'file', which has been
corrected.
Graduated to 'master'.
cf. <CABPp-BFdwxTvkcWKNP0-Lk+mqQLnULoYuLHZe0aot4VYfHnjSw@mail.gmail.com>
source: <20260812162551.2229680-1-gitster@pobox.com>
* js/coverity-unchecked-returns-fix (2026-08-12) 12 commits
(merged to 'next' on 2026-08-17 at 105f002870)
+ bisect: handle dup() failure when redirecting stdout
+ bisect: check get_terms return at all call sites
+ bisect: check strbuf_getline_lf return when reading terms
+ transport-helper: warn when export-marks file cannot be finalized
+ transport-helper: check dup() return in get_exporter
+ compat/pread: check initial lseek for errors
+ last-modified: handle repo_parse_commit() failures
+ reftable tests: check reftable_table_init_ref_iterator() return
+ reftable/block: check deflateInit() return value
+ reftable: handle block-writer initialization errors
+ config: propagate launch_editor() failure in show_editor()
+ http: die on curl_easy_duphandle failure in get_active_slot
A handful of code paths have been corrected to check return values
from functions like curl_easy_duphandle(), deflateInit(), lseek(),
dup(), and strbuf_getline_lf(), resolving several Coverity warnings
about unchecked returns.
Graduated to 'master'.
cf. <an1k0d5fI4EVsfsM@pks.im>
source: <pull.2179.v3.git.1786521801.gitgitgadget@gmail.com>
* js/pack-objects-delta-size-t (2026-08-13) 13 commits
(merged to 'next' on 2026-08-17 at b6778ce373)
+ packfile: widen `unpack_object_header_buffer()` to `size_t`
+ git-zlib: widen `git_deflate_bound()` to `size_t`
+ t/helper/test-pack-deltas: widen `do_compress()`'s maxsize local to `size_t`
+ http-push: widen `start_put()`'s size local from `ssize_t` to `size_t`
+ diff: widen `deflate_it()`'s bound local from int to `size_t`
+ archive-zip: widen `zlib_deflate_raw()`'s maxsize local to `size_t`
+ packfile, git-zlib: widen `use_pack()` and zstream avail fields to `size_t`
+ delta: widen `create_delta()` and `diff_delta()` to `size_t`
+ pack-objects: widen `mem_usage` and `try_delta()`'s out-param to `size_t`
+ pack-objects: widen `free_unpacked()` return to `size_t`
+ pack-objects: widen delta-cache accounting to `size_t`
+ delta: widen `create_delta_index()` parameter to `size_t`
+ diff-delta: widen `struct delta_index`' size fields to `size_t`
The 'pack-objects' and delta-encoding code paths have been updated to
use 'size_t' instead of 'unsigned long' for object sizes and offset
limits, avoiding potential truncation issues on 64-bit Windows.
Graduated to 'master'.
cf. <xmqqbjb6t179.fsf@gitster.g>
source: <pull.2175.v3.git.1786632952.gitgitgadget@gmail.com>
* js/packfile-fast-append (2026-08-13) 1 commit
(merged to 'next' on 2026-08-18 at cc3da5a03d)
+ packfile: fix perf regression with many packs
The performance of adding numerous new packfiles has been improved
by introducing a fast path for known-new packfiles to skip an
unnecessary traversal in packfile_list_append(), avoiding a
quadratic complexity regression on load.
Graduated to 'master'.
cf. <an7ItVYrKZFXg2ci@pks.im>
cf. <xmqqy0e8pxos.fsf@gitster.g>
source: <pull.2202.v2.git.1786633010179.gitgitgadget@gmail.com>
* js/sequencer-release-odb-before-commit (2026-08-12) 1 commit
(merged to 'next' on 2026-08-15 at 1c83dffd7a)
+ sequencer: release the ODB before spawning git commit
The sequencer has been updated to release the object database before
spawning 'git commit'. This prevents open file handles from
blocking auto-maintenance tasks, such as repacking, on systems like
Windows where open files cannot be easily unlinked.
Graduated to 'master'.
cf. <xmqqqzk3xqxs.fsf@gitster.g>
source: <pull.2198.v2.git.1786528498689.gitgitgadget@gmail.com>
* kk/merge-base-exhaustion (2026-08-11) 11 commits
(merged to 'next' on 2026-08-15 at 3f836fa1e4)
+ commit-reach: remove commit-date ordering fallback
+ commit-reach: move min_generation check into paint_queue_get()
+ commit-reach: terminate merge-base walk when one paint side is exhausted
+ commit-reach: introduce struct paint_state with per-side counters
+ t6600: add clock-skew topologies and step counts for edge cases
+ commit-reach: add trace2 instrumentation to paint_down_to_common()
+ t6099: add side-exhaustion regression test
+ t6600: add test cases for side-exhaustion edge cases
+ test-lib-functions: improve diagnostic output for trace2 data assertions
+ Documentation/technical: add paint-down-to-common doc
+ Merge branch 'kk/commit-reach-find-all-fix' into kk/merge-base-exhaustion
The merge-base computation has been optimized by stopping the walk
early when one side's exclusive commits in the queue are exhausted,
yielding significant speedups for queries with one-sided histories.
Graduated to 'master'.
cf. <CABPp-BHuh_8q6Hy2-Bk7H6Chdb4+eeW1f4LZU0szZ4zU9Eeo+w@mail.gmail.com>
cf. <xmqqbjb7w1dq.fsf@gitster.g>
source: <pull.2149.v8.git.1786440533.gitgitgadget@gmail.com>
* ps/cat-file-remote-object-info-type (2026-08-07) 11 commits
(merged to 'next' on 2026-08-15 at 3f5daf59a8)
+ cat-file: unify default format
+ serve: advertise type capability
+ fetch-object-info: parse type from server response
+ protocol-caps: add type support to object-info
+ transport: drop remote object-info fields from transport struct
+ fetch-object-info: die() on the remaining error path
+ fetch-object-info: use dedicated struct for the results
+ fetch-object-info: pass arguments directly instead of a struct
+ fetch-object-info: detect malformed server responses
+ t5701: use test_file_size() to get the size of a file
+ Merge branch 'ps/cat-file-remote-object-info' into ps/cat-file-remote-object-info-type
The 'remote-object-info' command for 'git cat-file --batch-command'
has been extended to support the '%(objecttype)' placeholder.
Graduated to 'master'.
cf. <20260808074157.GA2915582@coredump.intra.peff.net>
cf. <CA+J6zkR5ZkUc8c=xiXgKiAYmbgcoyGfwpgm6aaG0Gog8OVmOjw@mail.gmail.com>
cf. <CAOLa=ZTrf_WHiRHTjBGAus+YbRsUkbR3dzsW=fgCK0jit6fYzQ@mail.gmail.com>
source: <20260808-objecttype-support-v6-0-e5cdaf27a49c@gmail.com>
* ps/odb-streams (2026-08-05) 8 commits
(merged to 'next' on 2026-08-15 at a8fbd74d00)
+ odb/streaming: unify function names to create new streams
+ odb/streaming: rename `struct input_zstream_data`
+ odb/streaming: rename `struct read_object_fd_data`
+ odb/streaming: consolidate read and write streams
+ odb/streaming: rename `struct odb_read_stream`
+ odb/streaming: support streaming arbitrary object types
+ odb/streaming: drop `is_finished` field
+ odb/streaming: track write stream size in the structure
The 'struct odb_read_stream' and 'struct odb_write_stream'
structures have been consolidated into a single unified 'struct
odb_stream' structure, simplifying object database streaming APIs
and enabling streaming of arbitrary object types.
Graduated to 'master'.
cf. <anuBdm29ye_qV_Rq@denethor>
source: <20260805-pks-odb-stream-unification-v2-0-b8c369564641@pks.im>
* ps/t7900-deflake-maintenance (2026-08-12) 2 commits
(merged to 'next' on 2026-08-17 at 7ef446fd59)
+ t7900: fix flaky "maintenance.strategy" test
+ t7900: adapt some tests to use a throwaway repository
Various tests in 't7900-maintenance.sh' have been updated to use a
throwaway repository, and auto-detaching of maintenance tasks is now
disabled for these tests to fix flaky races with concurrent background
maintenance jobs.
Graduated to 'master'.
cf. <CAOLa=ZQmZ0spmdPOzCZe36i24nQh+o7d4fSz5dcJS7+O3p2skg@mail.gmail.com>
source: <20260812-pks-t7900-fix-flaky-test-v2-0-9ea0e1ac0edd@pks.im>
* ss/repack-drop-filtered (2026-08-13) 6 commits
(merged to 'next' on 2026-08-18 at 23ad3f2b76)
+ builtin/repack: add guards for --drop-filtered
+ builtin/repack: actually drop filtered promisor blobs
+ builtin/repack: enumerate promisor blobs for --drop-filtered
+ repack-promisor: allow excluding objects from the rebuilt promisor pack
+ list-objects-filter: add list_objects_filter__filter_oidset()
+ builtin/repack: add --drop-filtered and --dry-run options
'git repack' has been taught '--drop-filtered' to delete local
promisor blobs exceeding a limit (currently 'blob:limit=') in partial
clones, reclaiming space. Guards prevent running during other
operations or if referenced by the index.
Graduated to 'master'.
cf. <CAP8UFD1esJ0fk3xPXvAmQhMK_5wrpGKZJg9YaFV0-qUAC7bf5g@mail.gmail.com>
source: <20260813200830.84348-1-r.siddharth.shrimali@gmail.com>
* ss/submittingpatches-typofix (2026-08-14) 1 commit
(merged to 'next' on 2026-08-18 at b251ddc3d7)
+ doc: fix typo in submitting patches
Typofix.
Graduated to 'master'.
cf. <xmqq7blsmru5.fsf@gitster.g>
source: <pull.2383.git.git.1786733219160.gitgitgadget@gmail.com>
--------------------------------------------------
[New Topics]
* dw/config-read-both-global (2026-08-23) 3 commits
- config: read global scope via config_sequence
- config: let sequence require a successful file
- path: use forward slashes in XDG config on Windows
The git config --global read operations have been updated to respect
both $HOME/.gitconfig and $XDG_CONFIG_HOME/git/config, fixing an
inconsistency where only the former was read when both configuration
files are present.
Waiting for response.
cf. <xmqqo6esti9o.fsf@gitster.g>
cf. <xmqqecfkhify.fsf@gitster.g>
cf. <xmqqy0dsg2vt.fsf@gitster.g>
cf. <xmqqse40g22c.fsf@gitster.g>
source: <20260823-fix-config-list-global-home-and-xdg-v2-0-b29cc63f017b@microsoft.com>
* vv/branch-recurse-no-start-ref (2026-08-21) 2 commits
- branch: allow recursion with no tracking name
- branch: do not track a start point with no ref
The --recurse-submodules option in 'git branch' has been fixed to
avoid a crash when the start point is not a reference (e.g., a raw
object ID). The creation path now skips setting up tracking and
properly forwards the absent tracking name to the submodule helper.
Needs review.
source: <20260822-vv-branch-recurse-no-start-ref-v1-0-46dc140acaa8@zitro.id>
* kn/reftable-optimize-reloading (2026-08-24) 4 commits
- reftable/stack: avoid reloading the stack when already locked
- reftable/stack: move list lock to `struct reftable_stack`
- reftable/stack: rename reftable_stack_new_addition()
- reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`
The reftable code has been optimized to avoid an unnecessary
stat/reload of the stack when an addition already holds the
list_file lock, reducing the number of newfstatat syscalls from
linear to constant when writing refs.
Will merge to 'next'?
cf. <ao1uqpCxFHlOyTV-@pks.im>
cf. <20260824225202.GA190620@coredump.intra.peff.net>
source: <20260824-740-optimize-reloading-the-reftable-stack-v2-0-9c9de2eb0af7@gmail.com>
* kh/format-patch-range-diff-notes (2026-08-24) 3 commits
- format-patch: learn --[no-]range-diff-notes
- revision.h: rename struct member to reflect notes role
- format-patch: simplify get_notes_arg parameters
The 'format-patch' command has been updated with options to
configure notes specifically for range-diff output, allowing them to
differ from the notes displayed on the patches themselves.
Waiting for response.
cf. <xmqqjypfp2vl.fsf@gitster.g>
source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
* jc/rerere-doc-typofix (2026-08-24) 1 commit
(merged to 'next' on 2026-08-25 at 62bdec98f9)
+ rerere: technical documentation typofix
A missing preposition in the rerere technical documentation has been
fixed.
Will merge to 'master'.
source: <xmqqtsojp4zf.fsf@gitster.g>
* ps/odb-alternates-at-creation (2026-08-25) 8 commits
- odb/source: remove the ability to write alternates
- builtin/clone: write alternates via `odb_create_on_disk()`
- odb/source: support writing alternates when creating the database
- builtin/clone: move setup of alternates for non-shared local clones
- builtin/clone: move setup of alternates for shared local clones
- builtin/clone: refactor handling of "--reference{,-if-able}"
- builtin/clone: move around `setup_reference()`
- builtin/clone: defer setup of the object database
- Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-alternates-at-creation
(this branch uses ps/odb-eagerly-load-alternates.)
The setup of alternates has been deferred to object database
creation time during clone, which drops the unused ad-hoc alternate
writing API, simplifying the object database backend interface.
Needs review.
source: <20260825-pks-odb-write-alternates-at-creation-time-v1-0-911513ba95c3@pks.im>
* ps/odb-pluggable-fsck (2026-08-25) 10 commits
- builtin/fsck: move loose object verification into the loose source
- builtin/fsck: move multi-pack index verification into the packed source
- builtin/fsck: move bitmap verification into the packed source
- builtin/fsck: move reverse index verification into the packed source
- builtin/fsck: move packfile verification into the packed source
- odb: provide infrastructure for pluggable fsck checks
- builtin/fsck: don't check alternates with "--no-full"
- builtin/fsck: de-globalize option handling
- builtin/fsck: merge `fsck_obj_buffer()` and `fsck_obj()`
- builtin/fsck: use `fsck_obj_buffer()` when checking loose objects
- Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-pluggable-fsck
- Merge branch 'ps/odb-pluggable-pack-generation' into ps/odb-pluggable-fsck
(this branch uses ps/odb-eagerly-load-alternates and ps/odb-pluggable-pack-generation.)
The consistency checks for the object database (fsck) have been
decoupled from the generic builtin implementation and moved into the
backend-specific object source layers, making them pluggable for
different object storage formats.
Needs review.
source: <20260825-pks-odb-source-fsck-v1-0-b756de0bf24f@pks.im>
* rs/worktree-add-basename-fixes (2026-08-25) 4 commits
- worktree add: let worktree_basename() return string copy
- worktree add: trim slashes when deriving branch name from path
- worktree add: reject separator-only path
- worktree add: don't read out of bounds in worktree_basename()
The string extraction logic for the branch name and worktree name
from the given path in 'git worktree add' has been corrected and
simplified to avoid out-of-bounds reads and improper handling of
trailing slashes.
Waiting for review.
cf. <xmqq33w2m186.fsf@gitster.g>
cf. <xmqqjypdj6g4.fsf@gitster.g>
source: <20260825180350.2099-1-l.s.r@web.de>
* en/no-amend-during-conflicts (2026-08-25) 1 commit
- commit: refuse to amend during conflict resolution
Teach 'am', 'revert', and 'rebase' that running 'commit --amend'
makes no sense during operations that stop and return control to
the user to resolve conflicts left in the working tree, just like
'cherry-pick' and 'merge' do.
Waiting for response.
cf. <4688ee19-b782-456a-bed2-8cd2a4415736@gmail.com>
cf. <xmqqqzjkj0p2.fsf@gitster.g>
source: <pull.2389.git.git.1787721681893.gitgitgadget@gmail.com>
--------------------------------------------------
[Stalled]
* ps/libgit-in-subdir (2026-07-12) 2 commits
. Move libgit.a sources into separate "lib/" directory
. t/helper: prepare "test-example-tap.c" for introduction of "lib/"
. Merge branch 'ps/odb-source-packed' into ps/libgit-in-subdir
The source files for 'libgit.a' have been moved into a new 'lib/'
directory to clean up the top-level directory and clearly separate
library code. This topic has been ejected for now, as it causes too
many evil merges with other topics.
Waiting for response for too long, stalled.
cf. <xmqqqzkx9t95.fsf@gitster.g>
cf. <al6yCTDjBRn2HGq0@com-79390>
cf. <xmqqqzk2t7sm.fsf@gitster.g>
cf. <xmqq7blo4g7g.fsf@gitster.g>
source: <20260713-pks-libgit-in-subdir-v4-0-696240876eb1@pks.im>
* hs/rebase-continue-edit (2026-07-21) 1 commit
- rebase: add --[no-]edit to --continue
Support for skipping the editor when continuing a rebase after
conflict resolution has been added with the '--no-edit' option, and
forcing it with '--edit'. A new configuration variable
'rebase.noEdit' can be used to set the default behavior.
Waiting for response for too long, stalled.
cf. <xmqqldb4xlqa.fsf@gitster.g>
cf. <db7edc66-9b2a-47bc-98db-87d01885cef0@gmail.com>
source: <20260721140443.1809379-2-hugo@hsal.es>
* sn/rebase-update-refs-symrefs (2026-07-22) 2 commits
- rebase: guard non-branch symref targets
- rebase: skip branch symref aliases
'git rebase --update-refs' has been taught to resolve local branch
symrefs to their referents before queuing updates, ensuring aliases of
the current branch are skipped and duplicate updates are avoided to
prevent failures when branch aliases are present.
Waiting for response for too long, stalled.
cf. <1eba5fb2-ab76-41e9-955d-e283256ad25d@gmail.com>
cf. <98682fa4-55d9-4829-97f1-02e244b35266@gmail.com>
source: <pull.2126.v3.git.1784708107.gitgitgadget@gmail.com>
* tb/pack-with-duplicates (2026-07-24) 5 commits
- pack-bitmap: handle duplicate pack entries during MIDX reuse
- test-tool bitmap: reject packs with duplicate objects
- midx: verify duplicate pack entries by OID and offset
- packfile: recover delta cycles through duplicate entries
- t5308: test reverse indexes with duplicate objects
The handling of packfiles with duplicate object entries has been
hardened. Specifically, reverse index lookup, delta cycle
recovery, multi-pack-index verification, and pack reuse paths have
been updated to correctly handle or gracefully reject duplicate
entries.
Waiting for response for too long, stalled.
cf. <xmqqecgs3vg6.fsf@gitster.g>
source: <cover.1784927134.git.ttaylorr@openai.com>
* tc/replay-linearize (2026-07-28) 3 commits
- replay: offer an option to linearize the commit topology
- replay: resolve the replay base outside pick_regular_commit()
- replay: add helper to put entry into replayed_commits
The 'git replay' command has been taught the '--linearize' option to
drop merge commits and linearize the replayed history, mimicking 'git
rebase --no-rebase-merges'.
Waiting for response for too long, stalled.
cf. <anYLeQj4Sx2vZqvy@denethor>
cf. <CABPp-BEFGku8msiJCcXburV+tcersr6uqEumKaPh-TguA1LjSg@mail.gmail.com>
source: <20260728-toon-git-replay-drop-merges-v8-0-ced11dffe749@iotcl.com>
* cl/regexec-macos-leak (2026-07-28) 2 commits
- SQUASH???
- regexec: work around macOS TRE leak on invalid UTF-8
A compatibility workaround has been introduced for macOS to address
a memory leak in the system regex engine when it encounters invalid
multibyte sequences. The workaround segments the input buffer at
invalid byte boundaries and searches each valid segment separately
using regexec(), avoiding the leaking path.
Waiting for response for too long, stalled.
cf. <xmqqse52bpa9.fsf@gitster.g>
cf. <anL7qL2-4h8ZlLcg@pks.im>
source: <20260728052538.12429-1-chungmin@chungminlee.com>
* cc/lazy-fetch-trusted-bit (2026-08-13) 5 commits
- builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo
- upload-pack: read uploadpack.lazyFetchTrusted
- setup: add 'allow_dot' arg to path_allowlist_apply()
- setup: extract path_allowlist_apply()
- promisor-remote: factor out lazy_fetch_objects()
A new 'uploadpack.lazyFetchTrusted' configuration variable has been
introduced to allow 'upload-pack' to lazily fetch missing objects from
configured promisor remotes when serving trusted repositories.
Waiting for response for too long, stalled.
cf. <xmqq1pc0mr5i.fsf@gitster.g>
cf. <xmqqecg0oabe.fsf@gitster.g>
cf. <xmqqy0e8mv0k.fsf@gitster.g>
cf. <xmqqjypsoami.fsf@gitster.g>
cf. <xmqq1pc0mr5i.fsf@gitster.g>
source: <20260813154748.2378747-1-christian.couder@gmail.com>
--------------------------------------------------
[Cooking]
* as/utimensat-utimes (2026-08-21) 3 commits
- compat/posix: drop legacy <utime.h> header and shims
- treewide: use utimensat(2) instead of legacy utime(3p)
- compat/posix: introduce utimensat(2) wrapper
The codebase has been updated to use the newer utimensat() POSIX
function instead of the obsolescent utime(), allowing
high-precision timestamps while preserving fallback compatibility.
Waiting for response.
cf. <aonIVn-ZQoMKWCAd@fruit.crustytoothpaste.net>
source: <pull.2209.git.1787322203.gitgitgadget@gmail.com>
* ps/fetch-packfile-uris-parallel (2026-08-21) 2 commits
- fetch-pack: allow parallelizing packfile URI fetches
- fetch-pack: prepare for threaded fetching of packfile URIs
The `git fetch` and `git clone` commands have been optimized to
download packfile URIs in parallel when the new
`fetch.packfileURIThreads` configuration is set, significantly
speeding up fetches from servers that advertise multiple packfiles.
Needs review.
source: <20260821-pks-parallelize-fetching-packfile-uris-v1-0-0df52d9427ce@pks.im>
* ps/odb-geometric-repack-loose-threshold (2026-08-11) 1 commit
(merged to 'next' on 2026-08-24 at f91738c4a4)
+ odb/files: be less aggressive with geometric repacking
The threshold for geometric repacking to trigger based on loose
object count has been adjusted to match that of 'git gc --auto',
preventing over-aggressive repacking during concurrent writes.
Will merge to 'master'.
cf. <aoTcxJSmKWNhnjZ9@denethor>
cf. <CABPp-BHgyVTHB_OGmCL4JprFFe6_MapOQNSjUOhJxu-+oWbErg@mail.gmail.com>
source: <20260811-pks-geometric-maintenance-reduce-frequency-v1-1-7a54c42355ac@pks.im>
* kn/receive-report-hook (2026-08-26) 3 commits
- hook: introduce the receive-report hook
- receive-pack: move message generation to separate function
- doc: add proc-receive hook info in 'git-receive-pack.adoc'
A new hook 'report' is added to 'git receive-pack', which runs after
reference updates and allows the server to filter or modify the
packet-line status report sent back to the client.
Needs review.
source: <20260826-758-introduce-hook-v4-0-6b14975ad957@gmail.com>
* en/midx-missing-pack-fallback (2026-08-25) 4 commits
- packfile: recover when a multi-pack-index names a removed pack
- packfile: recover object lookups racing a concurrent repack
- mktree: plug per-tree leak in --batch mode
- replay: fail gracefully when a merge input is unreadable
- Merge branch 'ps/odb-generic-corrupt-objects' into en/midx-missing-pack-fallback
(this branch uses ps/odb-generic-corrupt-objects.)
The object lookup machinery has been taught to gracefully recover
when a multi-pack-index points to an owning pack that was removed
during a concurrent geometric repack, and 'git replay' has been
fixed to not segfault when reading such missing objects.
Needs review.
source: <pull.2207.v2.git.1787684429.gitgitgadget@gmail.com>
* ll/zsh-complete-git-potty-options (2026-08-19) 1 commit
- completion: zsh: support completion after "git -C <path>"
The zsh completion script (in 'contrib/') has been updated to
correctly locate the Git command after global options like '-C' by
properly skipping them, similar to how the bash completion does.
Needs review.
cf. <CALnO6CC35iuyJpKZtkEN7fGuGK7zKd_jbebyZdKSQ1pyfOBRZA@mail.gmail.com>
source: <pull.2155.v2.git.1787144872870.gitgitgadget@gmail.com>
* ps/odb-generic-corrupt-objects (2026-08-19) 5 commits
(merged to 'next' on 2026-08-23 at fe72e268a1)
+ odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically
+ odb/source: allow `read_object_info()` to bubble up error messages
+ odb/source: let callers discern missing and corrupt objects
+ odb/source: introduce error status when reading objects
+ odb/source-packed: flag known-bad objects as corrupt and not missing
(this branch is used by en/midx-missing-pack-fallback.)
The object database (odb) API has been refactored to distinguish
between missing objects and corrupt ones by returning more
descriptive error statuses. Both the packed and loose backends now
faithfully propagate error details using a generic strbuf error
mechanism, removing backend-specific leakage from central lookup
paths.
Will merge to 'master'.
cf. <CAOLa=ZTVxdVAJynKjb0LjmZ-+b5nQmyD0Bm-aT81rOOdJ0a5yg@mail.gmail.com>
source: <20260819-pks-odb-generic-corrupt-objects-v2-0-a984e3a0ad6f@pks.im>
* ap/http-preserve-wwwauth-redirect (2026-08-19) 1 commit
- http: preserve wwwauth_headers across redirects
When an HTTP request triggers a redirect and the target yields an
authentication challenge, the WWW-Authenticate headers received
during the redirect are now explicitly preserved across the
credential URL update, fixing an issue where they were incorrectly
cleared.
Needs review.
source: <20260819-http-preserve-wwwauth-redirect-v2-1-4c61039432b0@nvidia.com>
* fr/pack-objects-trace-pack-bytes (2026-08-19) 1 commit
(merged to 'next' on 2026-08-24 at dcc6a34978)
+ pack-objects: trace pack bytes written
The pack-objects command has been updated to record the total bytes
written to pack files in trace2 output, allowing performance
analysis of different compression settings by comparing the
resulting pack sizes.
Will merge to 'master'.
cf. <aobFLJuiuM1EuNpv@pks.im>
cf. <20260820082102.GA2973952@coredump.intra.peff.net>
source: <c6a8cdac36d2202055d637ebcc97e484122cdcd4.1787158152.git.friel@openai.com>
* kh/doc-datamodel (2026-08-23) 4 commits
- doc: datamodel: link to the glossary
- doc: glossary: link four of the terms to gitdatamodel(7)
- doc: git: link to the gitdatamodel(7) tutorial
- doc: git: list gitdatamodel(7) as a concept guide
The gitdatamodel documentation page has been linked from a handful
of key documentaiton pages.
Needs review.
source: <V2_CV_doc_datamodel_advertize.c20@msgid.xyz>
* yn/worktree-repair-relative (2026-08-21) 1 commit
- worktree repair: detect relative path in .git file correctly
The git worktree repair command failed to rewrite the .git file of
a working tree from a relative path to an absolute path when the
command was run in the working tree itself. The
read_gitfile_gently() function was modified to also return whether
the path originally recorded in the file was absolute, and this new
capability is used to correctly detect such mismatches.
Needs review.
cf. <xmqq4ignyv1z.fsf@gitster.g>
source: <pull.2205.v3.git.1787344586470.gitgitgadget@gmail.com>
* sk/object-name-use-after-free (2026-08-17) 1 commit
(merged to 'next' on 2026-08-20 at b0804dff5f)
+ object-name: avoid use-after-free in get_oid_with_context_1()
A heap-use-after-free bug in the object name parsing code when
reporting failures with a relative path to a sparse directory has
been corrected.
Will merge to 'master'.
cf. <xmqq1pbw7nwi.fsf@gitster.g>
source: <20260817082127.81132-1-diy2903@gmail.com>
* kh/format-rev-doc-synopsis (2026-08-17) 2 commits
(merged to 'next' on 2026-08-20 at b9c47eddd0)
+ doc: format-rev: use [synopsis] on code block
+ doc: format-rev: quote subject placeholder before and after
The documentation for 'git format-rev' has been updated to use the
[synopsis] block definition on code blocks to properly highlight
placeholders, and a quoting inconsistency in the running text has
been fixed.
Will merge to 'master'.
cf. <xmqq33wc4dyq.fsf@gitster.g>
source: <V4_CV_synopsis_block.b8e@msgid.xyz>
* kh/format-rev-more-options (2026-08-18) 5 commits
- format-rev: learn --abbrev, --color, and --date
- doc: rev-list-options.adoc: factor out --date alts
- format-rev: factor option variables into a struct
- format-rev: place BUG calls first in callback
- format-rev: use lower case for opts description
The experimental 'git format-rev' has been taught a few more
formatting options.
Needs review.
source: <V2_CV_format-rev_three_more_opts.bd3@msgid.xyz>
* ps/odb-pluggable-pack-generation (2026-08-20) 6 commits
(merged to 'next' on 2026-08-24 at 4d8acd97d0)
+ bundle: generate packfiles via the object database
+ bundle: get (mostly) rid of `the_repository`
+ builtin/bundle: refactor option handling for progress meter
+ send-pack: generate packfiles via the object database
+ upload-pack: generate packfiles via the object database
+ odb: introduce interface to generate packfiles
(this branch is used by ps/odb-pluggable-fsck.)
The mechanism to generate a packfile corresponding to the result of
a fetch/push has been made pluggable through a set of object
database callback functions, removing hardcoded references to
'pack-objects' and enabling alternative ODBs to serve packfiles
themselves.
Will merge to 'master'.
cf. <CABPp-BHAeb5Q6kWw8e0fz9+avKyJL0_k7cUzRhesHScJjB3Xfw@mail.gmail.com>
cf. <CAOLa=ZQMjb1SzYTVVuMF0ajmre_5_q=L6bmSQwYY233f-RiVXA@mail.gmail.com>
source: <20260821-b4-pks-odb-generate-pack-v4-0-074e8bd641f8@pks.im>
* ty/repository-fetch-if-missing (2026-08-14) 1 commit
(merged to 'next' on 2026-08-25 at 2cc77c1ca1)
+ repository: move fetch_if_missing into struct repository
The global variable 'fetch_if_missing' has been moved to a member in
'struct repository', continuing the libification process and
allowing per-repository control (such as for submodules).
Will merge to 'master'.
cf. <xmqqmrun8jeu.fsf@gitster.g>
source: <20260815064747.2196896-1-cat@malon.dev>
* ns/ref-symref-additional-tests (2026-08-20) 2 commits
- t1402: test forbidden characters in refnames
- t1401: check symbolic-ref failure and --quiet silence on a non-symbolic ref
A few tests for the reference handling subsystem have been added to
exercise the handling of forbidden characters and symbolic references.
Needs review.
source: <pull.2203.v2.git.1787264417682.gitgitgadget@gmail.com>
source: <pull.2204.v3.git.1787763107646.gitgitgadget@gmail.com>
* jt/receive-pack-pluggable-writes (2026-08-20) 9 commits
(merged to 'next' on 2026-08-24 at cf024e685d)
+ odb/transaction: add transaction interface to write packfiles
+ odb: return temporary ODB source when set
+ builtin/receive-pack: explicitly pass packfile fd
+ builtin/receive-pack: report unpack errors via strbuf
+ builtin/receive-pack: lift global state out of unpack()
+ builtin/receive-pack: read unpack limit config lazily
+ builtin/receive-pack: pass shallow file explicitly
+ odb/transaction: add transaction finalize interface
+ builtin/receive-pack: properly clean up keep files
The 'git receive-pack' command has been updated to use a new ODB
transaction interface for writing incoming packfiles, making it more
backend-agnostic.
Will merge to 'master'.
cf. <aohD54ZQEyybw008@pks.im>
cf. <xmqqo6evqzsu.fsf@gitster.g>
source: <20260820234940.894624-1-jltobler@gmail.com>
* ps/odb-eagerly-load-alternates (2026-08-17) 5 commits
(merged to 'next' on 2026-08-24 at a431cd5887)
+ odb: drop `alternates_db` field
+ odb: drop `loaded_alternates` field
+ odb: eagerly initialize alternates
+ odb: decouple source path comparisons from `the_repository`
+ setup: create ref and object databases after config is written
+ Merge branch 'ps/odb-make-creation-pluggable' into ps/odb-eagerly-load-alternates
(this branch is used by ps/odb-alternates-at-creation and ps/odb-pluggable-fsck.)
The object database layer has been simplified by eagerly loading
alternate object directories upon initialization, instead of
deferring it to the first object lookup. This eliminates the need
for scattered lazy-loading calls throughout the codebase and paves
the way for integrating alternates with the pluggable backends.
Will merge to 'master'.
cf. <CAOLa=ZReodSXjEbQkFoxcofMLq6mUOjXANRg7bZ2uEKKQn=DXw@mail.gmail.com>
cf. <xmqqik53qz5j.fsf@gitster.g>
source: <20260817-pks-odb-eagerly-prepare-alternates-v3-0-1115a7e02467@pks.im>
* gg/http-ssl-verify-status (2026-08-18) 1 commit
- http: add http.sslVerifyStatus to check stapled OCSP responses
The HTTP transport has been taught to check the revocation status of
the server certificate using the stapled OCSP response during the
TLS handshake via a new 'http.sslVerifyStatus' configuration
variable.
Needs review.
source: <20260818214858.65122-1-ggordon@gitlab.com>
* ty/repo-config-cleanups (2026-08-07) 3 commits
- environment: remove inaccurate repo_config_values comments
- environment: clarify repository config getter documentation
- environment: drop redundant NULL checks in config getters
Repository configuration getters in 'environment.c' have been
simplified by removing redundant NULL checks. The documentation for
these getters in 'environment.h' has been clarified, and inaccurate
section comments inside 'struct repo_config_values' have been removed.
Needs review.
source: <20260807085932.3958759-1-cat@malon.dev>
* vm/complete-history (2026-08-13) 4 commits
(merged to 'next' on 2026-08-24 at f6498b4afc)
+ completion: complete 'git history split' pathspecs
+ completion: complete 'git history --update-refs' values
+ completion: complete 'git history --empty' values
+ completion: add 'git history' subcommands
The command line completion (in contrib/) has been taught to handle
the experimental 'git history' command.
Will merge to 'master'.
cf. <aoWP3TYq5rNjUx7S@pks.im>
cf. <xmqqse49uanx.fsf@gitster.g>
source: <20260813-history_autocompletion-v3-0-69eed1cea93a@kernel.org>
* dk/use-nsec-runtime (2026-08-20) 3 commits
- core: convert build-time USE_NSEC into runtime core.useNanosec
- environment: align repo_config_values_init with struct declaration
- meson: expose knob for xmlto relative links in manuals
The build-time knob 'USE_NSEC' for nanosecond stat precision has been
converted to a runtime configuration 'core.useNanosec', allowing
distributions to bundle one binary that adapts to filesystem
capabilities dynamically.
Expecting a (hopefully a small and final) reroll.
cf. <xmqqa4qgsn20.fsf@gitster.g>
cf. <aoaP7oIrR_Bpvx34@pks.im>
cf. <CALnO6CC-=0X2r6USab=6MBG-yWYrwrA6zEXnDC91P8q4WDeY8Q@mail.gmail.com>
source: <cover.1787231825.git.ben.knoble@gmail.com>
* bc/restrict-hex-to-lowercase (2026-07-29) 6 commits
- hex: allow only lowercase object IDs in breaking changes mode
- object-name: use hexval
- hex: label usages of hex parsing for object IDs
- hex: make hex_to_bytes accept kind of hex to use
- hex: allow specifying hex type with hex2chr
- hex: add functionality for lowercase-only hex
The parser for hex object names has been updated to reject uppercase
hexadecimal characters when running in the breaking changes mode, in
preparation for Git 3.0.
Expecting a reroll.
cf. <ao4MJQgp6Ai4tJxi@fruit.crustytoothpaste.net>
cf. <ao4MqtDxZJaMEBBI@fruit.crustytoothpaste.net>
source: <20260729233215.398654-1-sandals@crustytoothpaste.net>
* js/mingw-build-updates (2026-08-12) 12 commits
- mingw: allow `git.exe` to be used instead of the "Git wrapper"
- mingw: ensure valid CTYPE
- mingw: always define `ETC_*` for MSYS2 environments
- windows: skip linking `git-<command>` for built-ins
- mingw: rely on MSYS2's metadata instead of hard-coding it
- mingw: only enable the MSYS2-specific stuff when compiling in MSYS2
- mingw: set the prefix and HOST_CPU as per MSYS2's settings
- mingw: avoid over-specifying `--pic-executable`
- mingw: only use -Wl,--large-address-aware for 32-bit builds
- mingw: drop the -D_USE_32BIT_TIME_T option
- mingw: stop hard-coding `CC = gcc`
- mingw: include the Python parts in the build
A collection of patches from Git for Windows has been upstreamed,
mostly focusing on simplifying and robustifying build configurations
for MinGW/MSYS2, dropping obsolete compatibility options, and allowing
the main 'git.exe' to be used directly without the extra wrapper
process on Windows.
Waiting for response.
cf. <4f4129df-681f-4e99-8b1f-8bb96e206a2d@kdbg.org>
source: <pull.2195.v2.git.1786521173.gitgitgadget@gmail.com>
* yn/worktree-add-no-dwim-with-b (2026-08-20) 1 commit
(merged to 'next' on 2026-08-23 at 6e4bf24274)
+ worktree add: shouldn't dwim if -b or -B is given
The DWIM logic in 'git worktree add' sometimes tried to infer a
remote-tracking branch when an explicit '-b' or '-B' option was
given to create a new branch, causing the explicit branch name to
be ignored, which has been corrected.
Will merge to 'master'.
cf. <xmqqecfssnk0.fsf@gitster.g>
source: <pull.2192.v4.git.1787221888406.gitgitgadget@gmail.com>
* yn/worktree-ambiguous-remote-advice (2026-08-26) 4 commits
- worktree add: treat multiple matches with --guess-remote as an error
- worktree add: improve message for ambiguous remote branch name
- checkout: improve message for ambiguous remote branch name
- checkout: extract function to display advice for ambiguous remotes
'git worktree add' did not prevent DWIM behavior when '-b' or '-B' was
specified, which has been corrected.
Needs review.
source: <pull.2197.v9.git.1787741111.gitgitgadget@gmail.com>
* hn/ci-cancel-stale-pr-runs (2026-07-31) 1 commit
- ci: cancel stale pull request workflow runs
GitHub Actions CI workflow runs triggered by pull requests have
been configured to cancel older runs when a new push is made to the
same pull request.
Waiting for response.
cf. <xmqqa4q8fyjh.fsf@gitster.g>
source: <pull.2369.git.git.1785492641983.gitgitgadget@gmail.com>
* kh/trailers-no-urls (2026-08-20) 1 commit
(merged to 'next' on 2026-08-24 at 11e10f8626)
+ trailers: stop recognizing URLs as trailers
+ Merge branch 'kh/doc-trailers' into kh/trailers-no-urls
The trailer parsing machinery has been updated to avoid mistaking
lines that begin with a URL (e.g., 'https://...') as trailer lines.
This prevents intended textual URLs from being mangled or mistakenly
treated as metadata keys.
Will merge to 'master'.
cf. <20260821004248.GA296777@coredump.intra.peff.net>
cf. <xmqqecfrqxic.fsf@gitster.g>
source: <V3_URLs_not_trailers.bfc@msgid.xyz>
* hn/checkout-m-autostash-refine (2026-07-25) 2 commits
- checkout -m: refine autostash fallback
- sequencer: teach autostash apply to report conflicts
The autostash fallback in 'git checkout -m' has been refined to only
retry when there are local changes. Additionally, a blank line now
visually separates autostash conflict advice from the subsequent
branch-switch message.
Needs review.
source: <pull.2364.git.git.1784993669.gitgitgadget@gmail.com>
* kj/repo-info-more-path-keys (2026-08-25) 7 commits
- repo: add path.cdup
- repo: add path.git-prefix
- repo: add path.grafts with absolute and relative suffixes
- repo: add path.index with absolute and relative suffixes
- repo: add path.hooks with absolute and relative suffixes
- repo: add path.superproject-root with absolute and relative suffixes
- repo: add path.toplevel with absolute and relative suffix formatting
The 'git repo info' command has been taught more keys to output
paths of various repository components (such as the working tree
root, superproject working tree, object database, etc.), supporting
both absolute and relative path formats.
Needs review.
source: <20260825175818.645579-1-jayatheerthkulkarni2005@gmail.com>
* tc/last-modified-bloom (2026-08-07) 6 commits
- last-modified: keep per-path Bloom filters for wildcard pathspecs
- last-modified: check pathspec against Bloom filter first
- revision: add Bloom check that includes parent directories
- bloom: add helper to check if any key in a vector is present
- revision: expose check for paths maybe changed in Bloom filter
- revision: move bloom keyvec precondition into function
The 'git last-modified' command has been optimized by using Bloom
filters. It now reuses revision walk filtering logic from 'git log'
to pre-filter commits, and maintains per-path Bloom filters even when
wildcard pathspecs are used.
Waiting for response.
cf. <xmqqtsp4a6c2.fsf@gitster.g>
source: <20260807-toon-speed-up-last-modified-v2-0-7d87bbdeaf9b@iotcl.com>
* ds/trace2-tolerate-failed-timestamp (2026-08-25) 7 commits
- trace2: remove use of xcalloc()
- trace2: remove use of ALLOC_GROW()
- trace2: remove use of xstrfmt()
- trace2: remove use of ALLOC_ARRAY()
- trace2: remove use of xstrdup()
- trace2: tolerate failed timestamp formatting
- banned-die: create header for banning of functions
The trace2 API has been updated to avoid calling 'die()' (by banning
the use of certain functions like xcalloc and xstrfmt) to prevent
unwanted process exits and recursion.
Waiting for response.
cf. <CABPp-BHxpt1UBTY5LCn9OFMZ6EtOcUPc-61RMWvjpjDBmv1rzg@mail.gmail.com>
cf. <CABPp-BFsSPJutOKManq-55ri=ddBpWLfN16xSNVs9O7+c2z0cg@mail.gmail.com>
source: <pull.2178.v2.git.1787684181.gitgitgadget@gmail.com>
* pz/fetch-submodule-errors-config (2026-07-16) 2 commits
- fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal
- submodule: fix premature failure in recursive submodule fetch
The 'git fetch' command can now configure how submodule fetch errors
are handled via 'fetch.submoduleErrors' and '--submodule-errors',
making them non-fatal. A premature failure during recursive submodule
fetches has been fixed by deferring the error until the OID-based
retry phase fails.
Needs review.
source: <20260716140956.1023740-1-paulius.zaleckas@gmail.com>
* gr/add-e-use-apply-api (2026-07-10) 1 commit
- builtin/add.c: replace run_command() with direct apply_all_patches() call
The application of the edited patch in 'git add -e' has been
refactored to use the internal apply API directly, avoiding the need
to spawn a 'git apply' subprocess.
Will merge to 'next'?
cf. <xmqqbjaoiyzx.fsf@gitster.g>
source: <20260711061246.58079-1-gatlavishweshwarreddy26@gmail.com>
* fz/rebase-autosquash-empty (2026-07-11) 1 commit
. sequencer: honor --empty when a fixup!/squash! empties its target
A commit that is emptied by melding a 'fixup!' or 'squash!' commit
during 'git rebase --autosquash' is now handled according to the
'--empty' option, allowing it to be dropped, kept, or to halt the
rebase. This topic has been ejected due to conflicts with
'pw/rebase-drop-notes-with-commit'.
Expecting a reroll.
cf. <DKJ2CZKJC6P0.VHLMCUDH6Z44@gmail.com>
source: <20260711-fz-autosquash-empty-v3-1-d227b63eb511@gmail.com>
* mm/lib-httpd-cgi-safe (2026-08-12) 3 commits
- t/lib-httpd: document writing concurrency-safe CGI helpers
- t/lib-httpd: make http-429 first-request check atomic
- t/lib-httpd: fix apply-one-time-script race under concurrent requests
CGI helper scripts used by HTTP-related test scripts have been updated
to use atomic filesystem operations, preventing race conditions when
Apache handles concurrent requests.
Needs review.
source: <pull.2171.v3.git.1786583137.gitgitgadget@gmail.com>
* ij/subtree-reject-v2-config (2026-07-06) 2 commits
- git-subtree: Bail out if we find output from Rust rewrite (test)
- git-subtree: Bail out if we find output from Rust rewrite
The shell script implementation of 'git subtree' has been updated to
check for the presence of the configuration file of the new Rust
implementation, preventing users from accidentally running the old
script on repositories already managed by the new tool.
Expecting a reroll.
cf. <27219.20156.438730.881821@chiark.greenend.org.uk>
source: <20260706115816.20267-1-ijackson@chiark.greenend.org.uk>
* zy/apply-abandoned-header-fix (2026-07-01) 1 commit
. apply: avoid leaking abandoned git-header state
A candidate 'git diff' header parsed by 'git apply' has been isolated
in a temporary structure, preventing any partially parsed state from
polluting the main patch structure and causing assertions to trip if
the header is ultimately rejected.
Will discard.
source: <20260702041759.51572-1-zhihao.yao@njit.edu>
* mm/line-log-limited-ops (2026-06-27) 7 commits
- diffcore-pickaxe: scope -G to the -L tracked range
- diff: support --check with -L line ranges
- line-log: support diff stat formats with -L
- diff: extract a line-range diff helper for reuse
- diff: emit -L hunk headers via xdiff's formatter
- diff: simplify the line-range filter by classifying removals immediately
- diff: rename and group the line-range filter for clarity
(this branch is used by mm/diff-process-hunks.)
The 'git log -L<range>:<path>' command has been taught to limit
various 'diff' operations, such as '--stat', '--check', and '-G', to
the specified range and path.
Needs review.
source: <pull.2152.v2.git.1782581342.gitgitgadget@gmail.com>
* hn/history-squash (2026-08-20) 8 commits
- history: support editing squashed commit messages
- history: create squashed commits without editing
- history: protect branches when squashing a range
- history: validate squash revision ranges
- history: add skeleton for squash subcommand
- sequencer: share the squash message marker helpers and flags
- history: give commit_tree_ext a message template
- history: extract helper for a commit's parent tree
The experimental 'git history' command has been taught a new 'squash'
subcommand to fold a range of commits into a single commit, with any
descendants replayed on top.
Waiting for response.
cf. <xmqq4igov9h9.fsf@gitster.g>
source: <pull.2337.v14.git.git.1787249432.gitgitgadget@gmail.com>
* tb/midx-incremental-custom-base (2026-06-12) 3 commits
- midx-write: include packs above custom incremental base
- midx: pass custom '--base' through incremental writes
- t5334: expose shared `nth_line()` helper
The 'git multi-pack-index write --incremental' command has been
corrected to properly honor the '--base' option. Previously, the
custom base was ignored by the normal write path; packs from layers
above the selected base were incorrectly skipped by the pack exclusion
logic, and reachability closure for bitmaps was broken.
Expecting a reroll.
cf. <an4uIQA09rDCwwBp@com-79390>
source: <cover.1781294771.git.me@ttaylorr.com>
* mm/diff-process-hunks (2026-08-13) 11 commits
- fixup! diff: consult oid-only hunk providers via diff.<driver>.process
- diff: consult oid-only hunk providers via diff.<driver>.process
- userdiff: add diff.<driver>.process config
- sub-process: add a gentle status read
- sub-process: separate process lifecycle from hashmap management
- blame: read precomputed hunks
- diff: read precomputed hunks for stat output
- diff: record precomputed hunks during stat output
- diff-hunks: add the store format, library, and command
- diff: introduce a hunk provider interface
- gitattributes: document how external diff drivers relate to diff features
- Merge branch 'mm/line-log-limited-ops' into mm/diff-process-hunks
(this branch uses mm/line-log-limited-ops.)
A new 'diff.<driver>.process' configuration has been introduced to
allow a long-running external process to act as a hunk provider,
enabling external tools to control which lines Git considers changed
while leaving all output formatting (word diff, color, blame, etc.) to
Git's standard pipeline.
Expecting a reroll.
cf. <CAC2Qwm+kzT_3_GKrpay=JLGYsxS10oWCg2MJPHrCVogFHA0OdA@mail.gmail.com>
source: <20260801174156.2998808-1-mmontalbo@gmail.com>
* ec/commit-fixup-options (2026-05-26) 2 commits
- commit: allow -c/-C for all kinds of --fixup
- commit: allow -m/-F for all kinds of --fixup
Support for '-m', '-F', '-c', or '-C' options to supply a commit log
message from outside the editor has been added for all 'git commit
--fixup' variations.
Needs review.
source: <cover.1779792311.git.erik@cervined.in>
^ permalink raw reply [flat|nested] 21+ messages in thread* kh/format-patch-range-diff-notes
2026-08-26 23:21 What's cooking in git.git (Aug 2026, #11) Junio C Hamano
@ 2026-08-27 6:06 ` Kristoffer Haugsbakk
0 siblings, 0 replies; 21+ messages in thread
From: Kristoffer Haugsbakk @ 2026-08-27 6:06 UTC (permalink / raw)
To: Junio C Hamano, git
On Thu, Aug 27, 2026, at 01:21, Junio C Hamano wrote:
> * kh/format-patch-range-diff-notes (2026-08-24) 3 commits
> - format-patch: learn --[no-]range-diff-notes
> - revision.h: rename struct member to reflect notes role
> - format-patch: simplify get_notes_arg parameters
>
> The 'format-patch' command has been updated with options to
> configure notes specifically for range-diff output, allowing them to
> differ from the notes displayed on the patches themselves.
>
> Waiting for response.
> cf. <xmqqjypfp2vl.fsf@gitster.g>
> source: <CV_format-patch_learn_--range-diff-notes.c57@msgid.xyz>
I posted a response.
<16315616-097a-4fe2-8665-010e424afd8b@app.fastmail.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2026-09-25 9:53 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-22 0:11 What's cooking in git.git (Sep 2026, #08) Junio C Hamano
2026-09-22 8:11 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
2026-09-22 13:25 ` Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Johannes Schindelin
2026-09-22 13:49 ` Junio C Hamano
2026-09-22 17:06 ` Johannes Schindelin
2026-09-24 3:56 ` Junio C Hamano
2026-09-24 4:30 ` Junio C Hamano
2026-09-24 12:29 ` Johannes Schindelin
2026-09-24 17:00 ` Junio C Hamano
2026-09-24 18:08 ` Ramsay Jones
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
2026-09-24 12:31 ` Johannes Schindelin
2026-09-25 9:53 ` Luca Milanesio
2026-09-23 12:52 ` D. Ben Knoble
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
2026-09-24 12:38 ` Johannes Schindelin
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
2026-09-23 15:15 ` Git Contributor' summit: Documentation, Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2026-09-04 23:55 What's cooking in git.git (Sep 2026, #02) Junio C Hamano
2026-09-05 6:31 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
2026-08-26 23:21 What's cooking in git.git (Aug 2026, #11) Junio C Hamano
2026-08-27 6:06 ` kh/format-patch-range-diff-notes Kristoffer Haugsbakk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox