{"thread":{"id":"66362","subject":"What's cooking in git.git (Sep 2026, #08)","startedAt":"2026-09-22T00:11:58Z","lastAt":"2026-09-25T09:53:34Z","messageCount":19,"participants":["Junio C Hamano","Kristoffer Haugsbakk","Johannes Schindelin","Daniele Sassoli","D. Ben Knoble","Toon Claes","Ramsay Jones","Luca Milanesio"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"552964","messageId":"xmqqwlsei1pv.fsf@gitster.g","threadId":"66362","inReplyTo":null,"subject":"What's cooking in git.git (Sep 2026, #08)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-22T00:11:56Z","receivedAt":"2026-09-22T00:11:58Z","isPatch":false,"body":"Here are the topics that have been cooking in my tree. Commits\nprefixed with '+' are in 'next' (being in 'next' is a sign that a\ntopic is stable enough to be used and is a candidate to be in a\nfuture release). Commits prefixed with '-' are only in 'seen', and\naren't considered \"accepted\" at all. They may be annotated with a URL\nto a message that raises issues but they are by no means exhaustive.\nA topic without enough support may be discarded after a long period\nof no activity (of course, it can be resubmitted when new interest\narises).\n\nGit 2.56-rc1 has been tagged. We may merge last-minute fixes before\nthe final Git 2.56 release, but otherwise I do not expect any new\nfeature topics to be ready before the final, so most of the\nin-flight topics will stay cooking in 'next' until then. As\ndiscussed at the Git Contributors' Summit, the version after the\nupcoming Git 2.56 will be Git 2.98, scheduled near the end of this\nyear.\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors. Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-scm/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* tz/doc-pack-refs-and-refs-fixes (2026-09-15) 2 commits\n (merged to 'next' on 2026-09-16 at 127f3b13fa)\n + doc/refs: backtick-quote commands and options consistently\n + doc/pack-refs: convert synopsis and options to new style\n\n Doc updates.\n\n Graduated to 'master'.\n source: <20260912191509.844954-1-tmz@pobox.com>\n\n\n* yt/pathspec-negative-prefix (2026-09-14) 2 commits\n (merged to 'next' on 2026-09-16 at f4f244ea28)\n + dir: preserve pathspec prefix optimization with leading excludes\n + dir: do not apply prefix to negative pathspecs\n + Merge branch 'jc/pathspec-match-const' into yt/pathspec-negative-prefix\n\n The pathspec matching logic has been updated to avoid out-of-bounds\n memory accesses when a negative pathspec is shorter than the common\n prefix of positive pathspecs.\n\n Graduated to 'master'.\n source: <7CB757FB-1F2D-4EE6-8C31-8C2CD6D42397@ytausch.de>\n\n--------------------------------------------------\n[New Topics]\n\n* rr/upload-pack-swap-shallow-wanted-ref (2026-09-16) 1 commit\n - upload-pack: swap wanted-ref/shallow-info responses\n\n The server-side protocol v2 response order for 'wanted-refs' and\n 'shallow-info' has been swapped to match the client's expectation,\n fixing a fetch failure when the server has 'uploadpack.allowRefInWant'\n enabled and the client performs a shallow fetch.\n\n Will merge to 'next'.\n source: <20260916203221.5265-1-royceremer@gmail.com>\n\n\n* bs/runtime-prefix-obsd-getexecpath (2026-09-16) 1 commit\n - exec_cmd: RUNTIME_PREFIX on OpenBSD systems\n\n Git on OpenBSD historically lacked an authoritative mechanism to\n resolve its executable path, as it doesn't support the\n KERN_PROC_PATHNAME sysctl. With OpenBSD 8.0 introducing\n getexecpath(3), it is now utilized to provide proper RUNTIME_PREFIX\n resolution instead of relying on argv[0] fallback.\n\n Waiting for response.\n cf. \n source: \n\n\n* js/coverity-fixes (2026-09-17) 7 commits\n - test-read-midx: check midx_fill_entry() result\n - oss-fuzz: handle reftable iterator initialization failures\n - t/unit-tests: check reftable iterator initialization\n - rerere: do not record failed conflict resolution data\n - midx: validate incremental MIDX pack IDs\n - gpg-interface: make signature-prefix matching length-aware\n - wrapper: guard writev_in_full() against signed overflow\n\n Assorted fixes for code paths that are not careful with boundary and\n error conditions.\n\n Will merge to 'next'?\n cf. \n cf. \n source: \n\n\n* yt/winansi-die-lasterr-fix (2026-09-20) 1 commit\n - compat/winansi: fix die_lasterr() argument formatting\n\n The error reporting machinery in the WinANSI compatibility layer has\n been simplified to pass the exact Windows error code and correctly\n format arguments for fatal errors.\n\n Waiting for response.\n cf. \n source: <20260921062114.14450-1-yqtian668@gmail.com>\n\n\n* hd/diff-no-index-reverse-fix (2026-09-18) 1 commit\n - diff --no-index: fix -R with file/directory conflicts\n\n A bug in git diff --no-index that mishandled reverse (-R) output\n when conflicts existed between a file and a directory has been\n fixed.\n\n Will merge to 'next'?\n cf. <9b97c14b-1d25-409b-a72c-d8caf298bf87@web.de>\n cf. <0c82d50e-f2c0-4db6-ade8-7a403cac73da@intel.com>\n source: \n\n\n* js/gitlab-ci-windows-rust (2026-09-19) 4 commits\n - ci(gitlab,windows): provide GNU Rust's host-linker support\n - ci(gitlab,windows): fix Rust setup for GitLab's MinGW build\n - ci(gitlab,windows): preserve exclusions during dependency setup\n - ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds\n\n The Windows GitLab CI job has been updated to provision and use the\n GNU Rust toolchain for MinGW builds, fixing job failures caused by\n incomplete Rust setup and missing linker support.\n\n Will merge to 'next'?\n cf. \n source: \n\n--------------------------------------------------\n[Cooking]\n\n* jc/advice-config-set-global (2026-09-14) 1 commit\n - advice: give cut-and-pasteable advice to squelch\n\n The advice subsystem has been updated to suggest using the\n '--global' option when recommending a command snippet to squelch\n future advice messages, since global configuration is generally\n more appropriate for user-level preferences than per-repository\n settings.\n\n Needs review.\n source: \n\n\n* sg/precompile-git-compat-util (2026-09-14) 4 commits\n (merged to 'next' on 2026-09-21 at 68acceee5b)\n + Makefile: precompile \"git-compat-util.h\"\n + Makefile: reintroduce REFTABLE_OBJS\n + cmake: remove any \"$(*_OBJS)\" variables when parsing Makefile for sources\n + Makefile: remove XDIFF_OBJS initialization\n\n The 'Makefile' has been taught to precompile 'git-compat-util.h' to\n speed up overall compilation, while excluding sources that do not\n include the compatibility header.\n\n Will cook in 'next'.\n source: <20260915060952.569535-1-szeder.dev@gmail.com>\n\n\n* of/commit-reach-repo-awareness (2026-09-16) 1 commit\n - commit-reach: parse commits in the given repository\n\n The can_all_from_reach() and can_all_from_reach_with_flag()\n functions have been updated to accept a repository context,\n preventing bugs where submodule merging incorrectly reads from the\n superproject's commit-graph.\n\n Will merge to 'next'.\n source: <20260916134632.1424829-1-orestisflo@gmail.com>\n\n\n* hn/range-diff-matched-only (2026-09-15) 1 commit\n - range-diff: add --matched-only to skip one-sided commits\n\n The 'git range-diff' command has been augmented with a\n '--matched-only' option to skip commits that are only present on\n one side, allowing users to easily focus on only the commits that\n have been retained.\n\n Needs review.\n source: \n\n\n* jc/cocci-free-updates (2026-09-11) 2 commits\n (merged to 'next' on 2026-09-16 at 35b8bafa06)\n + cocci: FREE_AND_NULL(E) is safe to call on NULL\n + cocci: remove risky \"if (!E) free(E)\" conversion\n\n Updates to Coccinelle semantic patches to correctly handle the\n 'FREE_AND_NULL()' macro and avoid generating broken transformations\n for negated pointer checks.\n\n Will cook in 'next'.\n cf. <96aca004-0df4-4e21-b60a-0288239122cc@web.de>\n source: \n source: \n\n\n* jt/object-file-batch-fsync-fix (2026-09-13) 2 commits\n - object-file: flush transaction packfile before migrating objects\n - object-file: lift ODB reprepare out of packfile flush\n\n When 'core.fsyncMethod' is set to 'batch', the ODB transaction\n failed to properly flush large blob packfiles residing in the\n temporary directory before migrating the directory's contents to the\n main object store. The execution sequence has been corrected by\n performing the packfile flush before the temporary directory\n migration, averting failure.\n\n Waiting for review.\n cf. \n cf. \n source: \n\n\n* ak/refs-files-root-ref-lock (2026-09-11) 1 commit\n (merged to 'next' on 2026-09-16 at c8568ea3e1)\n + refs/files: avoid packed-refs lock for root ref deletion\n\n The files backend has been updated to avoid unconditionally locking\n the 'packed-refs' file when deleting a root ref (which are never\n packed).\n\n Will cook in 'next'.\n cf. \n source: <20260912014609.535922-1-skariel@gmail.com>\n\n\n* tb/rerere-wait-for-merge-rr-lock (2026-09-14) 2 commits\n - rerere: go on at a conflict when the lock stays busy\n - rerere: wait for MERGE_RR.lock, and let the gc skip it\n\n Instead of failing to record conflicts to be resolved immediately,\n wait while \"rerere gc\" is ongoing.\n\n Needs review.\n source: \n\n\n* pp/midx-write-skip-empty (2026-09-08) 1 commit\n - midx-write: skip writes with no object entries\n\n The `git multi-pack-index write` command has been updated to\n silently return success when there are no object entries to index.\n This avoids writing empty `multi-pack-index` layers, which\n previously caused subsequent incremental midx writes using the\n `--bitmap` option to fail when attempting to load the missing\n reverse index.\n\n Waiting for review.\n cf. \n cf. \n source: \n\n\n* jk/merge-ll-tempfile-cleanup (2026-09-11) 3 commits\n - merge-ll: use tempfile API for external driver files\n - merge-ll: catch close() errors when writing external tempfiles\n - merge-ll: use strbuf to read back external merge result\n\n The external merge driver in 'git merge' now uses the tempfile API\n to create its temporary files. This ensures that these temporaries\n are reliably cleaned up even when the merge driver or its parent Git\n process is terminated abruptly.\n\n Expecting a reroll.\n cf. <20260914165350.GA32247@peff.net>\n source: <20260911171044.GA1609692@coredump.intra.peff.net>\n\n\n* mh/rust-crate-subdir (2026-09-16) 1 commit\n - move rust gitcore crate to a different subdirectory\n\n The Rust code and its 'Cargo.toml' file have been moved from the\n top-level repository root and 'src/' directory into a dedicated\n 'rust/' subdirectory. This avoids confusing Cargo's packaging\n mechanism when the Git repository is included as a submodule in\n other Rust projects.\n\n Waiting for review.\n cf. \n source: <20260917060415.2986259-1-mh@glandium.org>\n\n\n* ps/ref-storage-format (2026-09-09) 13 commits\n (merged to 'next' on 2026-09-16 at 8937a6240b)\n + setup: allow \"--ref-storage-format=\" to specify a payload\n + setup: rename \"init.defaultRefFormat\" to \"init.defaultRefStorageFormat\"\n + t: rename GIT_TEST_DEFAULT_REF_FORMAT\n + setup: rename ref storage format environment variables\n + setup: refactor how we configure the ref storage format\n + refs: expose function to parse reference URIs\n + help: rename \"default-ref-format\" to \"default-ref-storage-format\"\n + builtin/rev-parse: rename \"--show-ref-format\" to \"--show-ref-storage-format\"\n + builtin/submodule: rename \"--ref-format=\" to \"--ref-storage-format=\"\n + builtin/refs: rename \"--ref-format=\" to \"--ref-storage-format=\"\n + builtin/clone: rename \"--ref-format=\" to \"--ref-storage-format=\"\n + builtin/init: rename \"--ref-format=\" to \"--ref-storage-format=\"\n + parse-options: allow for hidden aliases\n\n The terminology regarding reference storage formats has been unified\n across command-line options, environment variables, configuration\n variables, and source code, standardizing on the phrase \"ref storage\n format\" (e.g., `--ref-storage-format`, `'GIT_REF_STORAGE_FORMAT'`).\n Additionally, the `--ref-storage-format` option has been updated to\n accept payloads in the form `://`.\n\n Will cook in 'next'.\n cf. \n cf. <5e062976-d584-496d-84e0-e4b59c8f6876@gmail.com>\n source: <20260909-b4-pks-unify-ref-storage-format-v3-0-ca041fb40ad8@pks.im>\n\n\n* ta/command-list-guides-sync-lint (2026-09-10) 2 commits\n - lint-docs: check the guide list in command-list.txt\n - command-list.txt: add gitformat-loose(5) and gitpacking(7)\n - Merge branch 'kh/doc-datamodel' into ta/command-list-guides-sync-lint\n\n A new linter test has been added to Documentation/lint-manpages.sh\n to ensure that all non-command manual pages (guides and developer\n interfaces) listed in Documentation/Makefile are present in\n command-list.txt, replacing an older comment that reminded\n developers to keep them in sync.\n\n Needs review.\n cf. \n source: <20260910194351.20809-1-taahol@utu.fi>\n\n\n* ap/var-broken-down-idents (2026-09-14) 1 commit\n - var: support broken-down idents, signing key, multiple args, and -z\n\n The 'git var' command has been extended to expose individual\n identity components ('GIT_AUTHOR_NAME', etc.) and the commit\n signing key, and can now accept multiple variables to query at\n once, safely formatting the output with a new '-z' option.\n\n Expecting a reroll.\n cf. <20260915220228.42819-1-andrewpleeter@gmail.com>\n source: \n\n\n* tc/push-force-if-includes-fixes (2026-09-17) 3 commits\n - push: --force-if-includes should allow fast-forward\n - push: fix --force-if-includes non-branch advice\n - push: check pushed ref for --force-if-includes\n\n The '--force-if-includes' protection for 'git push' has been updated\n to consult the reflog of the local branch being pushed, rather than\n incorrectly checking the reflog of a local branch that shares the name\n of the remote destination branch. The push advice for detached HEAD\n scenarios has also been adjusted to indicate that the remote ref\n cannot be verified locally. A regression that caused perfectly valid\n fast-forward pushes to be rejected when reflogs were expired has been\n fixed.\n\n Needs review.\n source: <20260917224351.57171-1-tyler@tylercipriani.com>\n\n\n* as/push-force-if-includes-no-reflog (2026-09-05) 1 commit\n - push: fix --force-if-includes when remote-tracking ref has no reflog\n\n The timestamp used for checking the reflog of a remote-tracking\n branch during 'git push --force-if-includes' was left uninitialized\n when the reflog was completely empty, which has been corrected.\n\n Waiting for review.\n cf. \n cf. <20260909065639.47316-1-f@lex.la>\n source: <20260905171330.34646-1-f@lex.la>\n\n\n* tb/rerere-lock-grace (2026-09-17) 3 commits\n - sequencer: disable auto maintenance in spawned commands\n - rebase, cherry-pick, revert: run auto maintenance when done\n - config: add git_config_append_parameter()\n\n The sequencer machinery (used by 'git rebase', 'git cherry-pick', and\n 'git revert') has been updated to defer automatic maintenance tasks\n until the end of the operation, preventing nested 'git commit', 'git\n merge', and 'exec' commands from triggering GC operations that could\n contend for locks or delete open packs while the sequence is in\n progress.\n\n Needs review.\n source: \n\n\n* cc/lazy-fetch-trusted-bit (2026-09-08) 5 commits\n - builtin/upload-pack: set GIT_NO_LAZY_FETCH to 0 on trusted repo\n - promisor-remote: prevent infinite recursion when lazy fetching\n - upload-pack: read uploadpack.lazyFetchTrusted\n - setup: extract path_allowlist_apply()\n - promisor-remote: factor out lazy_fetch_objects()\n\n A new 'uploadpack.lazyFetchTrusted' configuration variable has been\n introduced to allow 'upload-pack' to lazily fetch missing objects from\n configured promisor remotes when serving trusted repositories.\n\n Waiting for response.\n cf. \n cf. \n cf. \n source: <20260908164129.560396-1-christian.couder@gmail.com>\n\n\n* cc/early-scan-options (2026-09-02) 6 commits\n - fast-import: use early_scan_options() for --allow-unsafe-features\n - parse-options: build early scan options from a struct option array\n - parse-options: add parse_options_takes_argument()\n - rev-parse: fix \"--\" detection when it is an option value\n - bisect: fix \"--\" detection when a term name is \"--\"\n - parse-options: add early_scan_options()\n\n The process of parsing command-line options in commands that\n perform an early scan over their arguments (such as 'git bisect',\n 'git rev-parse', and 'git fast-import') has been unified using a\n new early-scan sub-API, which parses and skips known options taking\n separate values to prevent logic bugs.\n\n Waiting for response.\n cf. \n source: <20260902161047.476753-1-christian.couder@gmail.com>\n\n\n* ec/commit-fixup-options (2026-05-26) 2 commits\n - commit: allow -c/-C for all kinds of --fixup\n - commit: allow -m/-F for all kinds of --fixup\n\n Support for '-m', '-F', '-c', or '-C' options to supply a commit log\n message from outside the editor has been added for all 'git commit\n --fixup' variations.\n\n Expecting a reroll.\n cf. \n source: \n\n\n* jc/checkout-refactor (2026-08-30) 8 commits\n - checkout: move post_checkout_hook() to checkout.c\n - checkout: wrap overly long lines\n - checkout: restructure switch, restore, and checkout entrypoints\n - checkout: extract branch setup and tracking helpers\n - checkout: extract option validation and pathspec helpers\n - checkout: validate stage and merge option compatibility in checkout_paths()\n - checkout: validate new branch name in checkout_branch()\n - checkout: pass cb_option explicitly to branch name parsers\n\n The front-end code for 'git checkout', 'git switch', and 'git\n restore' has been restructured to cleanly separate their pathspec\n and branch handling, eliminating a common bottleneck and paving the\n way to libify utility helpers.\n\n Waiting for response.\n cf. \n cf. \n source: <20260830204835.1040408-1-gitster@pobox.com>\n\n\n* ll/doc-pushcert-if-asked (2026-08-29) 1 commit\n - doc: remote-helpers: option pushcert if-asked\n\n The remote helper documentation for the 'pushcert' option has been\n updated to mention that it can also take 'if-asked', reflecting the\n existing implementation in the code.\n\n Needs review.\n source: <20260829183659.29947-1-lorenz.leutgeb@posteo.eu>\n\n\n* ws/squelch-svn-migrate (2026-08-27) 2 commits\n - Makefile: add NO_GIT_SVN knob to skip building/installing git-svn\n - git-svn: don't print v1-layout migration noise when there's nothing to migrate\n\n Needs review.\n source: <20260827234345.1037130-1-wesleys@opperschaap.net>\n\n\n* dw/config-read-both-global (2026-08-23) 3 commits\n - config: read global scope via config_sequence\n - config: let sequence require a successful file\n - path: use forward slashes in XDG config on Windows\n\n The git config --global read operations have been updated to respect\n both $HOME/.gitconfig and $XDG_CONFIG_HOME/git/config, fixing an\n inconsistency where only the former was read when both configuration\n files are present.\n\n Expecting a reroll.\n cf. \n source: <20260823-fix-config-list-global-home-and-xdg-v2-0-b29cc63f017b@microsoft.com>\n\n\n* vv/branch-recurse-no-start-ref (2026-08-21) 2 commits\n - branch: allow recursion with no tracking name\n - branch: do not track a start point with no ref\n\n The --recurse-submodules option in 'git branch' has been fixed to\n avoid a crash when the start point is not a reference (e.g., a raw\n object ID). The creation path now skips setting up tracking and\n properly forwards the absent tracking name to the submodule helper.\n\n Needs review.\n source: <20260822-vv-branch-recurse-no-start-ref-v1-0-46dc140acaa8@zitro.id>\n\n\n* ps/odb-alternates-at-creation (2026-09-10) 9 commits\n (merged to 'next' on 2026-09-15 at 4acaa6a8aa)\n + odb/source: remove the ability to write alternates\n + builtin/clone: write alternates via `odb_create_on_disk()`\n + odb/source: support writing alternates when creating the database\n + builtin/clone: move setup of alternates for non-shared local clones\n + builtin/clone: move setup of alternates for shared local clones\n + builtin/clone: refactor handling of \"--reference{,-if-able}\"\n + builtin/clone: move around `setup_reference()`\n + builtin/clone: defer setup of the object database\n + setup: split up concerns of `init_db()`\n + Merge branch 'ps/odb-eagerly-load-alternates' into ps/odb-alternates-at-creation\n\n The setup of alternates has been deferred to object database\n creation time during clone, which drops the unused ad-hoc alternate\n writing API, simplifying the object database backend interface.\n\n Will cook in 'next'.\n cf. \n source: <20260910-pks-odb-write-alternates-at-creation-time-v5-0-8d10c4238edc@pks.im>\n\n\n* as/utimensat-utimes (2026-08-21) 3 commits\n - compat/posix: drop legacy header and shims\n - treewide: use utimensat(2) instead of legacy utime(3p)\n - compat/posix: introduce utimensat(2) wrapper\n\n The codebase has been updated to use the newer utimensat() POSIX\n function instead of the obsolescent utime(), allowing\n high-precision timestamps while preserving fallback compatibility.\n\n Waiting for response for too long, stalled\n cf. \n source: \n\n\n* kn/receive-report-hook (2026-09-14) 5 commits\n (merged to 'next' on 2026-09-15 at aa6cbdb87e)\n + receive-pack: coccinelle fix\n + hook: introduce the receive-report hook\n + receive-pack: move message generation to separate function\n + receive-pack: drop static variables to track report status version\n + doc: add proc-receive hook info in 'git-receive-pack.adoc'\n\n A new hook 'report' is added to 'git receive-pack', which runs after\n reference updates and allows the server to filter or modify the\n packet-line status report sent back to the client.\n\n Will cook in 'next'.\n source: <20260910-758-introduce-hook-v10-0-06f9c506631c@gmail.com>\n source: \n\n\n* ap/http-preserve-wwwauth-redirect (2026-08-19) 1 commit\n - http: preserve wwwauth_headers across redirects\n\n When an HTTP request triggers a redirect and the target yields an\n authentication challenge, the WWW-Authenticate headers received\n during the redirect are now explicitly preserved across the\n credential URL update, fixing an issue where they were incorrectly\n cleared.\n\n Needs review.\n source: <20260819-http-preserve-wwwauth-redirect-v2-1-4c61039432b0@nvidia.com>\n\n\n* kh/format-rev-more-options (2026-08-18) 5 commits\n - format-rev: learn --abbrev, --color, and --date\n - doc: rev-list-options.adoc: factor out --date alts\n - format-rev: factor option variables into a struct\n - format-rev: place BUG calls first in callback\n - format-rev: use lower case for opts description\n\n The experimental 'git format-rev' has been taught a few more\n formatting options.\n\n Needs review.\n source: \n\n\n* gg/http-ssl-verify-status (2026-09-15) 1 commit\n - http: add http.sslVerifyStatus to check stapled OCSP responses\n\n The HTTP transport has been taught to check the revocation status of\n the server certificate using the stapled OCSP response during the\n TLS handshake via a new 'http.sslVerifyStatus' configuration\n variable.\n\n Will merge to 'next'?\n cf. \n source: <20260915162348.97792-1-ggordon@gitlab.com>\n\n\n* ty/repo-config-cleanups (2026-08-07) 3 commits\n - environment: remove inaccurate repo_config_values comments\n - environment: clarify repository config getter documentation\n - environment: drop redundant NULL checks in config getters\n\n Repository configuration getters in 'environment.c' have been\n simplified by removing redundant NULL checks. The documentation for\n these getters in 'environment.h' has been clarified, and inaccurate\n section comments inside 'struct repo_config_values' have been removed.\n\n Waiting for response for too long, stalled\n cf. \n source: <20260807085932.3958759-1-cat@malon.dev>\n\n\n* dk/use-nsec-runtime (2026-09-11) 3 commits\n (merged to 'next' on 2026-09-15 at 67ef6d82ef)\n + core: convert build-time USE_NSEC into runtime core.useNanosec\n + environment: align repo_config_values_init with struct declaration\n + meson: expose knob for xmlto relative links in manuals\n\n The build-time knob 'USE_NSEC' for nanosecond stat precision has been\n converted to a runtime configuration 'core.useNanosec', allowing\n distributions to bundle one binary that adapts to filesystem\n capabilities dynamically.\n\n Will cook in 'next'.\n cf. \n source: \n\n\n* bc/restrict-hex-to-lowercase (2026-09-07) 7 commits\n - hex: allow only lowercase object IDs in breaking changes mode\n - t5324: adjust tests for corrupt commit-graph\n - object-name: use hexval\n - hex: label usages of hex parsing for object IDs\n - hex: make hex_to_bytes accept kind of hex to use\n - hex: allow specifying hex type with hex2chr\n - hex: add functionality for lowercase-only hex\n\n The parser for hex object names has been updated to reject uppercase\n hexadecimal characters when running in the breaking changes mode, in\n preparation for Git 3.0.\n\n Needs review.\n source: <20260907195941.1024289-1-sandals@crustytoothpaste.net>\n\n\n* kj/repo-info-more-path-keys (2026-09-11) 7 commits\n - repo: add path.cdup\n - repo: add path.git-prefix\n - repo: add path.grafts with absolute and relative suffixes\n - repo: add path.index with absolute and relative suffixes\n - repo: add path.hooks with absolute and relative suffixes\n - repo: add path.superproject-root with absolute and relative suffixes\n - repo: add path.toplevel with absolute and relative suffix formatting\n\n The 'git repo info' command has been taught more keys to output\n paths of various repository components (such as the working tree\n root, superproject working tree, object database, etc.), supporting\n both absolute and relative path formats.\n\n Waiting for response.\n cf. \n cf. \n source: <20260911144519.1011780-1-jayatheerthkulkarni2005@gmail.com>\n\n\n* tc/last-modified-bloom (2026-09-01) 6 commits\n - last-modified: keep per-path Bloom filters for wildcard pathspecs\n - last-modified: check pathspec against Bloom filter first\n - revision: add Bloom check that includes parent directories\n - bloom: add helper to check if any key in a vector is present\n - revision: expose check for paths maybe changed in Bloom filter\n - revision: move bloom keyvec precondition into function\n\n The 'git last-modified' command has been optimized by using Bloom\n filters. It now reuses revision walk filtering logic from 'git log'\n to pre-filter commits, and maintains per-path Bloom filters even when\n wildcard pathspecs are used.\n\n Waiting for response.\n cf. \n cf. \n source: <20260901-toon-speed-up-last-modified-v4-0-a09949800404@iotcl.com>\n\n\n* ds/trace2-tolerate-failed-timestamp (2026-08-31) 7 commits\n - trace2: remove use of xcalloc()\n - trace2: remove use of ALLOC_GROW()\n - trace2: remove use of xstrfmt()\n - trace2: remove use of ALLOC_ARRAY()\n - trace2: remove use of xstrdup()\n - trace2: tolerate failed timestamp formatting\n - banned-die: create header for banning of functions\n\n Functions like `xstrfmt()` and `xcalloc()` have been banned from use\n in the trace2 API codebase to prevent calls to `die()` which lead to\n unwanted process exits and recursion when memory allocation fails.\n\n Needs review.\n source: \n\n\n* pz/fetch-submodule-errors-config (2026-07-16) 2 commits\n - fetch: add fetch.submoduleErrors to make submodule fetch errors non-fatal\n - submodule: fix premature failure in recursive submodule fetch\n\n The 'git fetch' command can now configure how submodule fetch errors\n are handled via 'fetch.submoduleErrors' and '--submodule-errors',\n making them non-fatal. A premature failure during recursive submodule\n fetches has been fixed by deferring the error until the OID-based\n retry phase fails.\n\n Needs review.\n source: <20260716140956.1023740-1-paulius.zaleckas@gmail.com>\n\n\n* fz/rebase-autosquash-empty (2026-08-27) 1 commit\n - sequencer: honor --empty when a fixup!/squash! empties its target\n\n A commit that is emptied by melding a 'fixup!' or 'squash!' commit\n during 'git rebase --autosquash' is now handled according to the\n '--empty' option, allowing it to be dropped, kept, or to halt the\n rebase.\n\n Waiting for response.\n cf. <511300fe-112d-4f20-bd3f-e401e68c4a27@gmail.com>\n source: <20260827-fz-autosquash-empty-v4-1-f98ffd575780@gmail.com>\n\n\n* ij/subtree-reject-v2-config (2026-07-06) 2 commits\n - git-subtree: Bail out if we find output from Rust rewrite (test)\n - git-subtree: Bail out if we find output from Rust rewrite\n\n The shell script implementation of 'git subtree' has been updated to\n check for the presence of the configuration file of the new Rust\n implementation, preventing users from accidentally running the old\n script on repositories already managed by the new tool.\n\n Expecting a reroll.\n cf. <27219.20156.438730.881821@chiark.greenend.org.uk>\n source: <20260706115816.20267-1-ijackson@chiark.greenend.org.uk>\n\n\n* mm/line-log-limited-ops (2026-09-02) 7 commits\n - diffcore-pickaxe: limit -G to the -L tracked range\n - diff: support --check with -L line ranges\n - diff: support stat formats with -L\n - diff: extract a line-range diff helper for reuse\n - diff: emit -L hunk headers via xdiff's formatter\n - diff: simplify the line-range filter by classifying removals immediately\n - diff: rename line-range filter struct and clarify fields\n (this branch is used by mm/diff-process-hunks.)\n\n The 'git log -L:' command has been taught to limit\n various 'diff' operations, such as '--stat', '--check', and '-G', to\n the specified range and path.\n\n Needs review.\n source: \n\n\n* hn/history-squash (2026-09-08) 8 commits\n (merged to 'next' on 2026-09-15 at 28dd773b8b)\n + history: support editing squashed commit messages\n + history: create squashed commits without editing\n + history: protect branches when squashing a range\n + history: validate squash revision ranges\n + history: add skeleton for squash subcommand\n + sequencer: share the squash message marker helpers and flags\n + history: give commit_tree_ext a message template\n + history: extract helper for a commit's parent tree\n\n The experimental 'git history' command has been taught a new 'squash'\n subcommand to fold a range of commits into a single commit, with any\n descendants replayed on top.\n\n Will cook in 'next'.\n cf. \n source: \n\n\n* tb/midx-incremental-custom-base (2026-06-12) 3 commits\n - midx-write: include packs above custom incremental base\n - midx: pass custom '--base' through incremental writes\n - t5334: expose shared `nth_line()` helper\n\n The 'git multi-pack-index write --incremental' command has been\n corrected to properly honor the '--base' option. Previously, the\n custom base was ignored by the normal write path; packs from layers\n above the selected base were incorrectly skipped by the pack exclusion\n logic, and reachability closure for bitmaps was broken.\n\n Expecting a reroll.\n cf. \n cf. \n source: \n\n\n* mm/diff-process-hunks (2026-08-13) 11 commits\n - fixup! diff: consult oid-only hunk providers via diff..process\n - diff: consult oid-only hunk providers via diff..process\n - userdiff: add diff..process config\n - sub-process: add a gentle status read\n - sub-process: separate process lifecycle from hashmap management\n - blame: read precomputed hunks\n - diff: read precomputed hunks for stat output\n - diff: record precomputed hunks during stat output\n - diff-hunks: add the store format, library, and command\n - diff: introduce a hunk provider interface\n - gitattributes: document how external diff drivers relate to diff features\n - Merge branch 'mm/line-log-limited-ops' into mm/diff-process-hunks\n (this branch uses mm/line-log-limited-ops.)\n\n A new 'diff..process' configuration has been introduced to\n allow a long-running external process to act as a hunk provider,\n enabling external tools to control which lines Git considers changed\n while leaving all output formatting (word diff, color, blame, etc.) to\n Git's standard pipeline.\n\n Expecting a reroll.\n cf. \n source: <20260801174156.2998808-1-mmontalbo@gmail.com>\n\n\n* kh/format-patch-range-diff-notes (2026-08-24) 3 commits\n . format-patch: learn --[no-]range-diff-notes\n . revision.h: rename struct member to reflect notes role\n . format-patch: simplify get_notes_arg parameters\n\n The 'format-patch' command has been updated with options to\n configure notes specifically for range-diff output, allowing them to\n differ from the notes displayed on the patches themselves.\n\n Expecting a reroll.\n cf. <8f0a076b-4822-44e2-a842-cc1e39ae1c1d@app.fastmail.com>\n source: \n"},{"id":"552972","messageId":"92ae04ac-6e94-4785-ae51-dbe794c07fad@app.fastmail.com","threadId":"66362","inReplyTo":"xmqqwlsei1pv.fsf@gitster.g","subject":"kh/format-patch-range-diff-notes","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-09-22T08:11:26Z","receivedAt":"2026-09-22T08:11:52Z","isPatch":false,"body":"On Tue, Sep 22, 2026, at 02:11, Junio C Hamano wrote:\n> * kh/format-patch-range-diff-notes (2026-08-24) 3 commits\n> . format-patch: learn --[no-]range-diff-notes\n> . revision.h: rename struct member to reflect notes role\n> . format-patch: simplify get_notes_arg parameters\n>\n> The 'format-patch' command has been updated with options to\n> configure notes specifically for range-diff output, allowing them to\n> differ from the notes displayed on the patches themselves.\n>\n> Expecting a reroll.\n> cf. <8f0a076b-4822-44e2-a842-cc1e39ae1c1d@app.fastmail.com>\n> source: \n\nI’ll comment since it’s almost been a month. It’s a straightforward\nreroll but I haven’t been able to do the about hour’s worth of work.\nI should get some time at the latest on the weekend.\n"},{"id":"552987","messageId":"76ac51df-cef8-c6a9-2610-8c21f03c6999@gmx.de","threadId":"66362","inReplyTo":"xmqqwlsei1pv.fsf@gitster.g","subject":"Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-22T13:25:57Z","receivedAt":"2026-09-22T13:26:02Z","isPatch":false,"body":"Hi Junio,\n\nOn Mon, 21 Sep 2026, Junio C Hamano wrote:\n\n> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n> the final Git 2.56 release, but otherwise I do not expect any new\n> feature topics to be ready before the final, so most of the\n> in-flight topics will stay cooking in 'next' until then. As\n> discussed at the Git Contributors' Summit, the version after the\n> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n> year.\n\nWould you say that the following is an accurate characterization of the\ntimeline, so that people who need to plan dependent projects can rely on\nit?\n\nThe participants of the Git Contributor Summit agreed on a certain release\nshape, rather than timing: release v2.99.1 and v3.0 simultaneously,\ndiffering only in the breaking-change defaults. The timeline discussed was\nv2.56 in September, v2.98 in December, then v2.99/v3.0 around March 2027;\nApril also came up. Dropping v2.57 in favor of v2.98 was an explicit\ndecision. This would make v3.0 principally a deliberate compatibility\ntransition, rather than a separate batch of features.\n\nRust was treated as mandatory for v3.0, and the explicit check for\nobjections drew none from anyone in the room. Compared with the\ncontentious portability discussion on the Git mailing list, that is a\nnotable signal. It does not establish that the portability problems\nthemselves are solved.\n\nOne of Git v3.0's bigger-impact challenges is SHA-256 interoperability,\nwhich is purportedly done, but not on the Git mailing list yet, and there\nwas affirmation that it will handle historical tags too. While GitLab\nalready has support for SHA-256, GitHub has it only in private preview\nwith general availablility likely before the end of the year. JGit does\n_not_ have SHA-256 support, and no participant knew of anyone funding it.\nThe ecosystem transition therefore remains uneven.\n\nIs this a fair summary of the \"Git v3.0\" breakout session at the Git\nContributor Summit, from your point of view?\n\nCiao,\nJohannes\n\n"},{"id":"552989","messageId":"xmqq4ifhgzvx.fsf@gitster.g","threadId":"66362","inReplyTo":"76ac51df-cef8-c6a9-2610-8c21f03c6999@gmx.de","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-22T13:49:06Z","receivedAt":"2026-09-22T13:49:18Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n> Hi Junio,\n>\n> On Mon, 21 Sep 2026, Junio C Hamano wrote:\n>\n>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n>> the final Git 2.56 release, but otherwise I do not expect any new\n>> feature topics to be ready before the final, so most of the\n>> in-flight topics will stay cooking in 'next' until then. As\n>> discussed at the Git Contributors' Summit, the version after the\n>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n>> year.\n>\n> Would you say that the following is an accurate characterization of the\n> timeline, so that people who need to plan dependent projects can rely on\n> it?\n\nMy outline was deliberately limited up to end of this year as I am\nhesitant to say beyond that point before the meeting notes are made\npublic. I am not sure who will be releasing it to the public and\nwhen, though with the open nature of this community I believe it\nwill happen soon. I do not recall anything controversial in the 3.0\nsection of the meeting notes.\n\n> Rust was treated as mandatory for v3.0, and the explicit check for\n> objections drew none from anyone in the room. Compared with the\n> contentious portability discussion on the Git mailing list, that is a\n> notable signal. It does not establish that the portability problems\n> themselves are solved.\n\nIt signals that the room was smaller than the list. Or enough time\npassed since we discussed some minority platforms having trouble\nwith Rust the last time to change the situation. Or little bit of\nboth ;-)\n\nThanks.\n"},{"id":"553002","messageId":"5f34a5a9-9f72-b725-666a-94798895d122@gmx.de","threadId":"66362","inReplyTo":"xmqq4ifhgzvx.fsf@gitster.g","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-22T17:06:55Z","receivedAt":"2026-09-22T17:06:57Z","isPatch":false,"body":"Hi Junio,\n\nOn Tue, 22 Sep 2026, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 21 Sep 2026, Junio C Hamano wrote:\n> >\n> >> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n> >> the final Git 2.56 release, but otherwise I do not expect any new\n> >> feature topics to be ready before the final, so most of the\n> >> in-flight topics will stay cooking in 'next' until then. As\n> >> discussed at the Git Contributors' Summit, the version after the\n> >> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n> >> year.\n> >\n> > Would you say that the following is an accurate characterization of the\n> > timeline, so that people who need to plan dependent projects can rely on\n> > it?\n> \n> My outline was deliberately limited up to end of this year as I am\n> hesitant to say beyond that point before the meeting notes are made\n> public. I am not sure who will be releasing it to the public and\n> when, though with the open nature of this community I believe it\n> will happen soon. I do not recall anything controversial in the 3.0\n> section of the meeting notes.\n\nFair enough: I did ask you to confirm my summit summary. Let me separate\nthat from what I need for planning: a proposal from you as release\nmaintainer can be discussed on the list on its own merits, without waiting\nfor publication of the meeting record or claiming summit consensus.\n\nCould you use the next What's cooking to outline your working release\nplan: whether paired 2.99.1/3.0 releases in March or April 2027 would be\nyour proposed target, what conditions could move it, and when we should\nreview that target?\n\nIf you cannot yet choose a target, could that update identify what needs\nresolving and when you expect to revisit the choice?\n\nYour assessment would give dependent projects a common baseline to\ncoordinate around. A provisional planning assumption would be useful; it\nneed not be a guarantee.\n\nThanks,\nJohannes\n"},{"id":"553006","messageId":"5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de","threadId":"66362","inReplyTo":"xmqq4ifhgzvx.fsf@gitster.g","subject":"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)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-22T18:44:41Z","receivedAt":"2026-09-22T18:44:44Z","isPatch":false,"body":"Hi Junio,\n\nOn Tue, 22 Sep 2026, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 21 Sep 2026, Junio C Hamano wrote:\n> >\n> >> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n> >> the final Git 2.56 release, but otherwise I do not expect any new\n> >> feature topics to be ready before the final, so most of the\n> >> in-flight topics will stay cooking in 'next' until then. As\n> >> discussed at the Git Contributors' Summit, the version after the\n> >> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n> >> year.\n> >\n> > Would you say that the following is an accurate characterization of the\n> > timeline, so that people who need to plan dependent projects can rely on\n> > it?\n> \n> My outline was deliberately limited up to end of this year as I am\n> hesitant to say beyond that point before the meeting notes are made\n> public.\n\nI originally wrote this summary of the Git Contributor Summit only for my\nown records, but since you hinted at wanting some meeting notes, figured\nit might be interesting to other people, too. So here goes my distillation\nof the breakout-sessions from this year's Contributors' Summit. Many of\nthese ideas still need discussion on the list; proposals below are not\nproject-wide decisions.\n\nSecurity mailing list and process\n\nThe security list is seeing a large influx of outside reports, apparently\noften AI-assisted or generated. Duplicates and reports outside Git's\nsecurity model consume triage time, while some patches have waited for\nmonths. Waiting for an empty queue is not a workable release criterion: we\nneed to release the fixes we have, rather than hold them indefinitely\nwhile more reports arrive. No fixed release cadence or guaranteed response\ntime was settled.\n\nDocumenting Git's security model would save repeated explanations of what\ndoes and does not constitute a vulnerability. (Personal note, not\ndiscussed at the Summit: Stolee had tried to start a conversation about\nGit's security boundary a long time ago, but nobody replied. Maybe the AI\nonslaught will provide enough motivation to get that discussion going.)\nMoving non-security bugs to the public list more readily was also\nencouraged. A timeout after which public discussion would be presumed OK\nwas proposed, but not agreed.\n\nMore company staffing would help, without turning this into an obligation\nfor volunteers. Paying for dedicated help was discussed, with onboarding\ncosts a concern. Using AI for triage or fixes raises confidentiality and\nDCO questions of its own. (Personal note: There seemed to be some\nsentiment in the room that contradicted the earlier agreed-on finding on\nthe mailing list that using AI for triaging and for investigating wasn't a\ncopyright concern and should therefore be considered permissible.)\n\nThe release bottleneck is not really tag automation. Merging and\nbackporting fixes, preparing advisories, and handling CVEs take work, and\ntoo much of that knowledge lives in people's heads. Peff volunteered to\nstart a public discussion of the process and dig up existing resources.\n(Personal note: I have done that merging, backporting, etc plenty of\ntimes, and I don't think that it is the bottleneck, and I was rather\nsurprised to hear that it is complicated. Sure, there are the expected\nmerge conflicts when merging `maint-*` branches, and running -- and\nfixing! -- CI on all of the tags in a private repository should go without\nsaying, but that's all craft of the trade. Rather, the indecision and lack\nof engagement on the git-security mailing list is what I see as the\nblocker. I'd happily volunteer to juggle those branch thickets if that was\ntruly the make-or-break issue here.)\n\nMicrosoft's release process reportedly needs about seven weeks. There were\nno objections in the room to proceeding without waiting for that schedule.\n(Personal note: That release process was misrepresented, which is\nsurprising, as I coordinated two or three Git for Windows security bugfix\nreleases _on the git-security list_ since the most recent Git security\nbugfix release, it's always the same thing: release on a second Tuesday of\nthe month, three weeks before that the patches need to have settled,\neverybody goes home with a dependable timeline. It's not really that big\nof a deal. Testing patches, constructive feedback, these are the things\nthat are missing and therefore blocking the process. I sensed a lot of\nfinger-pointing in this discussion. I mean, I don't blame anybody for\navoiding security work: it is stressful and intense. The responsibility\nfor getting things wrong is enormous. I know that because I've done my\nshare of that, probably more than most in the Git project, and I will do\neven more in the future. But when I don't have the time, or the energy, I\nam aware that I, myself, am the bottleneck; I don't need to blame others.)\n\nGit v3.0\n\nThe proposed target is spring 2027: v2.56 in September 2026, v2.98 in\nDecember, then v2.99 and v3.0 next spring. The jump in version numbers is\nintended to signal the approaching breaking changes. March and April were\nboth mentioned; the precise timing is not settled.\n\nThere was agreement on releasing v2.99.1 and v3.0 together, differing only\nin the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition\nseparate from another round of feature development. Nobody in the room\nobjected to Rust becoming mandatory in v3.0. (Personal note: probably\nbecause Randall wasn't there, to say that NonStop support would be a\nblocker and that Git please wait.) A v2.x LTS remains an open question,\nwith Gentoo mentioned as an interested party. (Personal note: I am still\nadvocating for an in-tree Long Term Support branch, and since Junio\nindicated that he's less than eager to take care of that, I would love for\nPatrick Steinhardt to be the \"LTS lieutenant\", I vaguely remember that he\nsaid he'd do it if asked, and I trust his judgement, so I'd ask.)\n\nSHA-256 support across the ecosystem had been a blocker. GitHub reported\nexperimental support, with general availability expected around November.\nGitLab already had public, non-experimental support, and libgit2 supports\nit, too. JGit remains a gap; Google was not planning to fund that work.\n\nThe SHA-1/SHA-256 interoperability work, including historical tags, was\nreported to be implemented but not yet sent to the list. (Personal note: I\nthink that the room seriously \"mis-underestimated\" the real-world impact\nof this. The code is not even on the Git mailing list, and the\nramifications of not having a robust plan how to deal with partial clones\nor submodules or even signed tags strikes me as a dealbreaker. I would not\nbe surprised if the decision to enforce SHA-256 as default would have to\nbe revisited before v3.0, and possibly overturned.)\n\nDocumentation\n\nJulia's work highlights the gap between documentation written by people\nwho know Git inside out and users who do not yet know what objects, the\nindex, or upstream mean. We need approachable learning material as well as\nreference documentation. Both need work; keeping manpages concise does not\nmean they cannot have better explanations and examples. (Personal note: I\nam beyond excited that Julia, whose work I have always admired, got\ninterested in improving Git's documentation, which is in dear need of\nbeing improved, mainly because it does not cater to the majority of Git\nusers out there who are unlikely to wander onto the Git mailing list,\never. I just hope that old-timers who really do not need the documentation\nnor understand the need of those who do need it show enough appreciation\nfor the fresh views and for Julia's understanding of the target audience.)\n\nDiscoverability matters, too. The website (https://git-scm.com/) needs\nclearer entry points for learning Git, and existing guides are harder to\nfind than manpages. Missing subsection links are another improvement we\ncould make incrementally. (Personal note: Judging by the history of that\nsite, I do wonder whether the core Git contributors are interested in\nhelping this effort at all. For example, there are a growing number of PRs\nsuggesting to add new UIs to the growing list, but I gave up reviewing\nthem because I was the only one doing so.)\n\nThere was support for replacing outdated material and for merging useful\nimprovements, then iterating, rather than trying to perfect everything\nbefore it lands. Bringing user feedback to the list without flooding it\nremains a challenge.\n\nThe current funding covers only 100 hours split between two people.\nAdditional project and company funding was encouraged; brian, Emily, and\nMark offered to explore company support. (Personal note: I had tried, back\nwhen GitHub still funded my team, to start something like that, without\nany success. To the contrary, even Git for Windows and Git Credential\nManager got defunded.)\n\nOn the tooling side, using only Asciidoctor instead of maintaining both\nAsciiDoc and Asciidoctor support was proposed as a possible Git v3.0\nchange. Distribution support and rendering differences need checking, with\ndoc-diff suggested for comparing the outputs. Patrick filed an issue\nduring the discussion. (Personal note: AFAIU the AsciiDoc spec is now\nmaintained by Asciidoctor, and I am aware already of one change that was\nmade to the spec without adapting AsciiDoc accordingly. So the entire\ndiscussion might be quite moot already.)\n\nOther ideas included richer diagrams for HTML while retaining text\nversions for manpages, and privacy-respecting traffic measurements to help\nprioritize documentation work. No diagram format was chosen, and caching\nand AI scraping complicate getting useful traffic data. Mermaid was\nproposed, and even GraphViz. (Personal note: I added support for Mermaid\ndiagrams to https://git-scm.com/, but it turned out to be too limited, so\nI added GraphViz support. The support code for this is a bit of a beast,\nhaving a wasm version of GraphViz for development, pre-rendering the\ndiagrams as SVG and as PDF during deployment of the site; it was quite a\nbit of fun to implement all that.)\n\nOutreachy sponsoring\n\nThe goal is to support three interns in the round starting in early\nDecember, at $10,000 each. The corporate sponsorship previously provided\nby GitLab and GitHub has dried up, leaving Git itself to pay. There are\ncompany contacts to follow up with; Emily offered to ask Google's OSPO,\nwithout high expectations. No new sponsorship commitments were made.\n(Personal note: I don't think that these internships provide enough\npublicity to give companies much of an incentive to fund this. Which I\nfind a bit of a shame, Outreachy in particular does a lot of important,\ngood work, and if I wasn't so constantly overworked, I would want to\nmentor again; I always found it rewarding, even if I hold myself to a\nquite high bar which is quite draining.)\n\nA related point for Git Merge 2027: announcing the location early would\nhelp Outreachy and GSoC interns plan attendance. No location was selected.\n\nPluggable object database\n\nPatrick's pluggable object database is working, but it is not complete:\ncommit-graph and multi-pack-index integration are still outstanding, and a\nrepository extension is planned. (Personal note: It might be interesting\nto see whether implementing a storage backend is easier in core Git or in\nanother Git-compatible implementation. JGit should be a natural target,\nhaving originated within BigTable-sized constraints, i.e. a different\nstorage system, but funding seems to have dried up, there's not even\nSHA-256 support, so JGit might not be as hackable as it once was.)\n\nContent-defined chunking prompted an important distinction between\nchanging how objects are stored and changing the logical object model.\nStarting at the storage layer would let us preserve existing blob OIDs\nrather than require ecosystem-wide changes. A new pack/index format could\nprovide another representation of the same object, much as deltas do\ntoday. No particular representation was agreed. (Personal note: It is\ncurious to me why nobody tought about inventing a \"meta blob\", i.e. an\nobject much like a tree object, except that it stitches together a larger\nblob. This would allow for the content-defined chunking that `rsync`\nalready championed, way before Git was born! It would have allowed a Git\nnative large file support worth writing home about, and could have\nreplaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would\nnot have had to be invented, and it would have allowed game development to\nmove to Git. I can only imagine that the time it would cost to get even\nthe first patches of this into core Git would be seen as prohibitive by\nany company who may have considered the effort.)\n\nThere is also an API question: does a backend seeing only object content\nhave enough context to make good storage and delta choices, or should it\nreceive richer information? More searchable tree storage and a Git \"commit\ncloud\" were other possibilities raised, not committed plans. (Personal\nnote: At a previous GitMerge, Facebook presented their work, see e.g.\nhttps://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,\nwhich includes separating actual storage from transport. That is, already\nat push time, derived metadata is computed in async jobs which provide\nseveral potential deltas ready-to-go when a client clones or fetches. They\nreported clones with regular Git clients that are twice as fast, just\nbecause the server doesn't need to spend much compute on the data it\nsends. So there is a lot to be learned out there already.)\n\nAI\n\nThe current SubmittingPatches policy is rooted in DCO certification and\nadvice from SFC lawyers. The unresolved question is whether, and to what\nextent, contributors can certify AI-generated code. There was substantial\ndisagreement about acceptable use, provenance and legal risks, community\ntrust, review burden, and whether the current caution excludes useful\ntools. No policy change was agreed. (Personal note: You'd think that the\nopinion of lawyers is taken at face value, but no, it seems that some core\nGit contributors seem to disagree with the lawyers in favor of their own\nopinion...)\n\nSeveral participants found language and proofreading assistance useful. A\nparticular concern was submissions where the human does little more than\nrelay agent output, leaving reviewers to deal with the consequences. The\ninflux of poor GSoC contributions was one example. Attribution such as\nAssisted-by was suggested to make tool use clearer, but attribution alone\ndoes not answer the quality or DCO questions. (Personal note: my precedent\nof \"Assisted-by\" was called out as helpful, and I do think it is. I make a\ndifference between AI-generated and AI-assisted. I'm not a fast typer, so\nI benefit a lot from being able to tell an LLM to please refactor out\nthese four lines with the appropriate signature. There's not much\ncreativity in there. I also like to let AI present me the call graphs for\ncertain code locations, because due to the choice of C, which thanks to\nthe C preprocessor is not easy to analyze statically, there are no\ncompetent tools other than LLMs that I can use for the task. I was highly\nsurprised, though, to see how much enmity against AI in general was\nvoiced, not by many, but many, many times, and how that contrasts with the\nLinux project which I hitherto had not considered to be as particularly\nopen to modern practices.)\n\nbrian and Taylor agreed to put differing policy proposals on the list. The\nsuggested process is to have alternatives examined by SFC counsel, make\nthe risks clear, and then consider a vote. Emily volunteered to organize\nthe voting procedure. Eligibility and the details remain open; Junio's\nauthority as maintainer remains central. (Personal note: Since Taylor\nworks for OpenAI now, I was not surprised by his stance, but brian works\nat GitHub, home of GitHub Copilot, and I am not sure how favorable their\nemployer would look at their semi-public utterings about AI...)\n\nProtocol v2 for pushes\n\nThere are concrete use cases now: repositories with millions of refs,\nincluding a reported 896 MB ref advertisement. Reftable improves ref\nupdate throughput, but does not by itself solve the advertisement problem.\nNobody objected to push protocol v2, and the fetch-v2 infrastructure\nalready provides much of the foundation.\n\nThe discussion covered advertising fewer refs, letting clients identify\nuseful branches, and replacing large advertisements with a few rounds of\npush negotiation. Negotiation results could also help optimize the\nserver's connectivity checks. Some improvements might be possible in the\nexisting protocol before introducing v2.\n\nWe need to measure the tradeoffs rather than assume fewer bytes means\nfaster pushes. One example involved a shallow push taking 35 seconds\ninstead of two because of work to minimize the transfer. Shallow\nboundaries and unrelated histories complicate the proposed heuristics.\n\nSHA-256 interoperability is another reason to want push v2: the current\npush protocol requires using the server's primary hash algorithm.\nNegotiation could make that more flexible.\n\nForge replication to thousands of mirrors would benefit from finding out\ncheaply whether refs have changed, rather than downloading full\nadvertisements from every target. Checksums, ETag-like values, and\nreftable generation numbers were discussed, with concurrent updates\ncomplicating the picture.\n\nCompact or compressed advertisements are also worth exploring and\nbenchmarking, possibly reusing reftable's format. That does not mean\nsending the server's actual reftable, including hidden refs. There are\nseveral promising directions here, but no final design yet.\n\nSome breakout sessions were planned, but apparently had to be cut.\n\nPersonal notes: I wasn't present for all of the sessions, in the afternoon\nI had other commitments; Therefore these notes (which AI assisted me in\ndistilling) came partially from what I dictated and partially from the\nshared Google Document in which a few volunteers gracefully wrote notes. I\nfound it challenging to connect as a remote participant. The link to the\nGoogle Meet, as well as control over the lobby thereof, seems to have been\nrestricted to at most a few people, which might have contributed to the\nlong waiting time before I was allowed in, and it definitely contributed\nto my comments not reaching the discussion in time to have an impact. I\nwould have loved for Junio or the other two brave souls who also\nparticipated remotedly to have had more \"air time\". I am still a fan of\nthe idea to have more frequent, smaller, virtual Contributor Summits,\norganized by a rotating cast. (Maybe I can get Emily to host the next\none.) I was very happy that Junio was participating, as he _is_ the\nproject lead, and in past Contributor Summits decisions were taken without\nhim, which I found odd. Timing was really challenging for him, though, it\nwas way past midnight for him. I'm all the more grateful that he\ndid participate.\n\nFinal remark: This summary is obviously biased. I lightly edited it to\nseparate better between my personal views and a hopefully unbiased account\nof what was discussed, and how, and by who. Nevertheless, I am but human.\nAs a consequence, I would be delighted if other participants would share\ntheir summaries, so that my bias can be balanced out.\n\nCiao,\nJohannes\n"},{"id":"553041","messageId":"c12b9da1-b679-43e5-9485-2cedeb1dc613@gmail.com","threadId":"66362","inReplyTo":"5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de","subject":"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)","fromName":"Daniele Sassoli","fromEmail":"danielesassoli@gmail.com","sentAt":"2026-09-23T11:55:32Z","receivedAt":"2026-09-23T11:55:39Z","isPatch":false,"body":"Hi Johannes,\n\nThanks so much for this summary, I didn't participate at the contributor \nsummit\nas I was leading one of the breakout sessions in the morning and had a \nplane to\ncatch in the afternoon, so I'm very grateful of your summary.\n\nOn 22/09/2026 19:44, Johannes Schindelin wrote:\n> Hi Junio,\n>\n> On Tue, 22 Sep 2026, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:\n>>>\n>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n>>>> the final Git 2.56 release, but otherwise I do not expect any new\n>>>> feature topics to be ready before the final, so most of the\n>>>> in-flight topics will stay cooking in 'next' until then. As\n>>>> discussed at the Git Contributors' Summit, the version after the\n>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n>>>> year.\n>>> Would you say that the following is an accurate characterization of the\n>>> timeline, so that people who need to plan dependent projects can rely on\n>>> it?\n>> My outline was deliberately limited up to end of this year as I am\n>> hesitant to say beyond that point before the meeting notes are made\n>> public.\n> I originally wrote this summary of the Git Contributor Summit only for my\n> own records, but since you hinted at wanting some meeting notes, figured\n> it might be interesting to other people, too. So here goes my distillation\n> of the breakout-sessions from this year's Contributors' Summit. Many of\n> these ideas still need discussion on the list; proposals below are not\n> project-wide decisions.\n>\n> Security mailing list and process\n>\n> The security list is seeing a large influx of outside reports, apparently\n> often AI-assisted or generated. Duplicates and reports outside Git's\n> security model consume triage time, while some patches have waited for\n> months. Waiting for an empty queue is not a workable release criterion: we\n> need to release the fixes we have, rather than hold them indefinitely\n> while more reports arrive. No fixed release cadence or guaranteed response\n> time was settled.\n>\n> Documenting Git's security model would save repeated explanations of what\n> does and does not constitute a vulnerability. (Personal note, not\n> discussed at the Summit: Stolee had tried to start a conversation about\n> Git's security boundary a long time ago, but nobody replied. Maybe the AI\n> onslaught will provide enough motivation to get that discussion going.)\n> Moving non-security bugs to the public list more readily was also\n> encouraged. A timeout after which public discussion would be presumed OK\n> was proposed, but not agreed.\n>\n> More company staffing would help, without turning this into an obligation\n> for volunteers. Paying for dedicated help was discussed, with onboarding\n> costs a concern. Using AI for triage or fixes raises confidentiality and\n> DCO questions of its own. (Personal note: There seemed to be some\n> sentiment in the room that contradicted the earlier agreed-on finding on\n> the mailing list that using AI for triaging and for investigating wasn't a\n> copyright concern and should therefore be considered permissible.)\n>\n> The release bottleneck is not really tag automation. Merging and\n> backporting fixes, preparing advisories, and handling CVEs take work, and\n> too much of that knowledge lives in people's heads. Peff volunteered to\n> start a public discussion of the process and dig up existing resources.\n> (Personal note: I have done that merging, backporting, etc plenty of\n> times, and I don't think that it is the bottleneck, and I was rather\n> surprised to hear that it is complicated. Sure, there are the expected\n> merge conflicts when merging `maint-*` branches, and running -- and\n> fixing! -- CI on all of the tags in a private repository should go without\n> saying, but that's all craft of the trade. Rather, the indecision and lack\n> of engagement on the git-security mailing list is what I see as the\n> blocker. I'd happily volunteer to juggle those branch thickets if that was\n> truly the make-or-break issue here.)\n>\n> Microsoft's release process reportedly needs about seven weeks. There were\n> no objections in the room to proceeding without waiting for that schedule.\n> (Personal note: That release process was misrepresented, which is\n> surprising, as I coordinated two or three Git for Windows security bugfix\n> releases _on the git-security list_ since the most recent Git security\n> bugfix release, it's always the same thing: release on a second Tuesday of\n> the month, three weeks before that the patches need to have settled,\n> everybody goes home with a dependable timeline. It's not really that big\n> of a deal. Testing patches, constructive feedback, these are the things\n> that are missing and therefore blocking the process. I sensed a lot of\n> finger-pointing in this discussion. I mean, I don't blame anybody for\n> avoiding security work: it is stressful and intense. The responsibility\n> for getting things wrong is enormous. I know that because I've done my\n> share of that, probably more than most in the Git project, and I will do\n> even more in the future. But when I don't have the time, or the energy, I\n> am aware that I, myself, am the bottleneck; I don't need to blame others.)\n>\n> Git v3.0\n>\n> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in\n> December, then v2.99 and v3.0 next spring. The jump in version numbers is\n> intended to signal the approaching breaking changes. March and April were\n> both mentioned; the precise timing is not settled.\n>\n> There was agreement on releasing v2.99.1 and v3.0 together, differing only\n> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition\n> separate from another round of feature development. Nobody in the room\n> objected to Rust becoming mandatory in v3.0. (Personal note: probably\n> because Randall wasn't there, to say that NonStop support would be a\n> blocker and that Git please wait.) A v2.x LTS remains an open question,\n> with Gentoo mentioned as an interested party. (Personal note: I am still\n> advocating for an in-tree Long Term Support branch, and since Junio\n> indicated that he's less than eager to take care of that, I would love for\n> Patrick Steinhardt to be the \"LTS lieutenant\", I vaguely remember that he\n> said he'd do it if asked, and I trust his judgement, so I'd ask.)\n>\n> SHA-256 support across the ecosystem had been a blocker. GitHub reported\n> experimental support, with general availability expected around November.\n> GitLab already had public, non-experimental support, and libgit2 supports\n> it, too. JGit remains a gap; Google was not planning to fund that work.\n>\n> The SHA-1/SHA-256 interoperability work, including historical tags, was\n> reported to be implemented but not yet sent to the list. (Personal note: I\n> think that the room seriously \"mis-underestimated\" the real-world impact\n> of this. The code is not even on the Git mailing list, and the\n> ramifications of not having a robust plan how to deal with partial clones\n> or submodules or even signed tags strikes me as a dealbreaker. I would not\n> be surprised if the decision to enforce SHA-256 as default would have to\n> be revisited before v3.0, and possibly overturned.)\n>\n> Documentation\n>\n> Julia's work highlights the gap between documentation written by people\n> who know Git inside out and users who do not yet know what objects, the\n> index, or upstream mean. We need approachable learning material as well as\n> reference documentation. Both need work; keeping manpages concise does not\n> mean they cannot have better explanations and examples. (Personal note: I\n> am beyond excited that Julia, whose work I have always admired, got\n> interested in improving Git's documentation, which is in dear need of\n> being improved, mainly because it does not cater to the majority of Git\n> users out there who are unlikely to wander onto the Git mailing list,\n> ever. I just hope that old-timers who really do not need the documentation\n> nor understand the need of those who do need it show enough appreciation\n> for the fresh views and for Julia's understanding of the target audience.)\n>\n> Discoverability matters, too. The website (https://git-scm.com/) needs\n> clearer entry points for learning Git, and existing guides are harder to\n> find than manpages. Missing subsection links are another improvement we\n> could make incrementally. (Personal note: Judging by the history of that\n> site, I do wonder whether the core Git contributors are interested in\n> helping this effort at all. For example, there are a growing number of PRs\n> suggesting to add new UIs to the growing list, but I gave up reviewing\n> them because I was the only one doing so.)\n>\n> There was support for replacing outdated material and for merging useful\n> improvements, then iterating, rather than trying to perfect everything\n> before it lands. Bringing user feedback to the list without flooding it\n> remains a challenge.\n>\n> The current funding covers only 100 hours split between two people.\n> Additional project and company funding was encouraged; brian, Emily, and\n> Mark offered to explore company support. (Personal note: I had tried, back\n> when GitHub still funded my team, to start something like that, without\n> any success. To the contrary, even Git for Windows and Git Credential\n> Manager got defunded.)\n>\n> On the tooling side, using only Asciidoctor instead of maintaining both\n> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0\n> change. Distribution support and rendering differences need checking, with\n> doc-diff suggested for comparing the outputs. Patrick filed an issue\n> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now\n> maintained by Asciidoctor, and I am aware already of one change that was\n> made to the spec without adapting AsciiDoc accordingly. So the entire\n> discussion might be quite moot already.)\n>\n> Other ideas included richer diagrams for HTML while retaining text\n> versions for manpages, and privacy-respecting traffic measurements to help\n> prioritize documentation work. No diagram format was chosen, and caching\n> and AI scraping complicate getting useful traffic data. Mermaid was\n> proposed, and even GraphViz. (Personal note: I added support for Mermaid\n> diagrams to https://git-scm.com/, but it turned out to be too limited, so\n> I added GraphViz support. The support code for this is a bit of a beast,\n> having a wasm version of GraphViz for development, pre-rendering the\n> diagrams as SVG and as PDF during deployment of the site; it was quite a\n> bit of fun to implement all that.)\n>\n> Outreachy sponsoring\n>\n> The goal is to support three interns in the round starting in early\n> December, at $10,000 each. The corporate sponsorship previously provided\n> by GitLab and GitHub has dried up, leaving Git itself to pay. There are\n> company contacts to follow up with; Emily offered to ask Google's OSPO,\n> without high expectations. No new sponsorship commitments were made.\n> (Personal note: I don't think that these internships provide enough\n> publicity to give companies much of an incentive to fund this. Which I\n> find a bit of a shame, Outreachy in particular does a lot of important,\n> good work, and if I wasn't so constantly overworked, I would want to\n> mentor again; I always found it rewarding, even if I hold myself to a\n> quite high bar which is quite draining.)\n>\n> A related point for Git Merge 2027: announcing the location early would\n> help Outreachy and GSoC interns plan attendance. No location was selected.\n>\n> Pluggable object database\n>\n> Patrick's pluggable object database is working, but it is not complete:\n> commit-graph and multi-pack-index integration are still outstanding, and a\n> repository extension is planned. (Personal note: It might be interesting\n> to see whether implementing a storage backend is easier in core Git or in\n> another Git-compatible implementation. JGit should be a natural target,\n> having originated within BigTable-sized constraints, i.e. a different\n> storage system, but funding seems to have dried up, there's not even\n> SHA-256 support, so JGit might not be as hackable as it once was.)\nPluggable backend implementations for JGit have been possible for quite some\ntime, although, admittedly, I don't think any made it to production. \nMaybe at\nthe time when this was introduced(16 years ago!!) by Shawn[1] in JGit it \nwasn't\nfashionable yet and so the project was never carried forward. I know Luca\nsubmitted a talk for the Gerrit User Summit to present a Cassandra \nback-end, for\nwhich I can see conversation started 10 years ago[2].\n\nRegarding JGit support's for SHA256, I know some corporations have had \ninterest\nin sponsoring this work and have discussed potentially implementing \ntogether it\nwith GerritForge, but, as far as I know, work isn't ongoing yet. JGit is \nstill\nvery much developed and kept up to date with great effort from the \ncommunity, so\nI believe it to still be as hackable as it was, there just hasn't been \nenough\ninterest for SHA-256 yet, which I agree is a shame, hopefully in the \nnear future\nthis gets remediated.\n\n[1] https://github.com/spearce/jgit_cassandra\n[2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE\n>\n> Content-defined chunking prompted an important distinction between\n> changing how objects are stored and changing the logical object model.\n> Starting at the storage layer would let us preserve existing blob OIDs\n> rather than require ecosystem-wide changes. A new pack/index format could\n> provide another representation of the same object, much as deltas do\n> today. No particular representation was agreed. (Personal note: It is\n> curious to me why nobody tought about inventing a \"meta blob\", i.e. an\n> object much like a tree object, except that it stitches together a larger\n> blob. This would allow for the content-defined chunking that `rsync`\n> already championed, way before Git was born! It would have allowed a Git\n> native large file support worth writing home about, and could have\n> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would\n> not have had to be invented, and it would have allowed game development to\n> move to Git. I can only imagine that the time it would cost to get even\n> the first patches of this into core Git would be seen as prohibitive by\n> any company who may have considered the effort.)\n>\n> There is also an API question: does a backend seeing only object content\n> have enough context to make good storage and delta choices, or should it\n> receive richer information? More searchable tree storage and a Git \"commit\n> cloud\" were other possibilities raised, not committed plans. (Personal\n> note: At a previous GitMerge, Facebook presented their work, see e.g.\n> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,\n> which includes separating actual storage from transport. That is, already\n> at push time, derived metadata is computed in async jobs which provide\n> several potential deltas ready-to-go when a client clones or fetches. They\n> reported clones with regular Git clients that are twice as fast, just\n> because the server doesn't need to spend much compute on the data it\n> sends. So there is a lot to be learned out there already.)\n>\n> AI\n>\n> The current SubmittingPatches policy is rooted in DCO certification and\n> advice from SFC lawyers. The unresolved question is whether, and to what\n> extent, contributors can certify AI-generated code. There was substantial\n> disagreement about acceptable use, provenance and legal risks, community\n> trust, review burden, and whether the current caution excludes useful\n> tools. No policy change was agreed. (Personal note: You'd think that the\n> opinion of lawyers is taken at face value, but no, it seems that some core\n> Git contributors seem to disagree with the lawyers in favor of their own\n> opinion...)\n>\n> Several participants found language and proofreading assistance useful. A\n> particular concern was submissions where the human does little more than\n> relay agent output, leaving reviewers to deal with the consequences. The\n> influx of poor GSoC contributions was one example. Attribution such as\n> Assisted-by was suggested to make tool use clearer, but attribution alone\n> does not answer the quality or DCO questions. (Personal note: my precedent\n> of \"Assisted-by\" was called out as helpful, and I do think it is. I make a\n> difference between AI-generated and AI-assisted. I'm not a fast typer, so\n> I benefit a lot from being able to tell an LLM to please refactor out\n> these four lines with the appropriate signature. There's not much\n> creativity in there. I also like to let AI present me the call graphs for\n> certain code locations, because due to the choice of C, which thanks to\n> the C preprocessor is not easy to analyze statically, there are no\n> competent tools other than LLMs that I can use for the task. I was highly\n> surprised, though, to see how much enmity against AI in general was\n> voiced, not by many, but many, many times, and how that contrasts with the\n> Linux project which I hitherto had not considered to be as particularly\n> open to modern practices.)\n>\n> brian and Taylor agreed to put differing policy proposals on the list. The\n> suggested process is to have alternatives examined by SFC counsel, make\n> the risks clear, and then consider a vote. Emily volunteered to organize\n> the voting procedure. Eligibility and the details remain open; Junio's\n> authority as maintainer remains central. (Personal note: Since Taylor\n> works for OpenAI now, I was not surprised by his stance, but brian works\n> at GitHub, home of GitHub Copilot, and I am not sure how favorable their\n> employer would look at their semi-public utterings about AI...)\n>\n> Protocol v2 for pushes\n>\n> There are concrete use cases now: repositories with millions of refs,\n> including a reported 896 MB ref advertisement. Reftable improves ref\n> update throughput, but does not by itself solve the advertisement problem.\n> Nobody objected to push protocol v2, and the fetch-v2 infrastructure\n> already provides much of the foundation.\n>\n> The discussion covered advertising fewer refs, letting clients identify\n> useful branches, and replacing large advertisements with a few rounds of\n> push negotiation. Negotiation results could also help optimize the\n> server's connectivity checks. Some improvements might be possible in the\n> existing protocol before introducing v2.\n>\n> We need to measure the tradeoffs rather than assume fewer bytes means\n> faster pushes. One example involved a shallow push taking 35 seconds\n> instead of two because of work to minimize the transfer. Shallow\n> boundaries and unrelated histories complicate the proposed heuristics.\n>\n> SHA-256 interoperability is another reason to want push v2: the current\n> push protocol requires using the server's primary hash algorithm.\n> Negotiation could make that more flexible.\n>\n> Forge replication to thousands of mirrors would benefit from finding out\n> cheaply whether refs have changed, rather than downloading full\n> advertisements from every target. Checksums, ETag-like values, and\n> reftable generation numbers were discussed, with concurrent updates\n> complicating the picture.\n>\n> Compact or compressed advertisements are also worth exploring and\n> benchmarking, possibly reusing reftable's format. That does not mean\n> sending the server's actual reftable, including hidden refs. There are\n> several promising directions here, but no final design yet.\n>\n> Some breakout sessions were planned, but apparently had to be cut.\n>\n> Personal notes: I wasn't present for all of the sessions, in the afternoon\n> I had other commitments; Therefore these notes (which AI assisted me in\n> distilling) came partially from what I dictated and partially from the\n> shared Google Document in which a few volunteers gracefully wrote notes. I\n> found it challenging to connect as a remote participant. The link to the\n> Google Meet, as well as control over the lobby thereof, seems to have been\n> restricted to at most a few people, which might have contributed to the\n> long waiting time before I was allowed in, and it definitely contributed\n> to my comments not reaching the discussion in time to have an impact. I\n> would have loved for Junio or the other two brave souls who also\n> participated remotedly to have had more \"air time\". I am still a fan of\n> the idea to have more frequent, smaller, virtual Contributor Summits,\n> organized by a rotating cast. (Maybe I can get Emily to host the next\n> one.) I was very happy that Junio was participating, as he _is_ the\n> project lead, and in past Contributor Summits decisions were taken without\n> him, which I found odd. Timing was really challenging for him, though, it\n> was way past midnight for him. I'm all the more grateful that he\n> did participate.\n>\n> Final remark: This summary is obviously biased. I lightly edited it to\n> separate better between my personal views and a hopefully unbiased account\n> of what was discussed, and how, and by who. Nevertheless, I am but human.\n> As a consequence, I would be delighted if other participants would share\n> their summaries, so that my bias can be balanced out.\n>\n> Ciao,\n> Johannes\n"},{"id":"553048","messageId":"CALnO6CDTeOHzudAMx=Zbg26_PXY2WAYw+kG6Mr9pyU0rJXMReQ@mail.gmail.com","threadId":"66362","inReplyTo":"5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de","subject":"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)","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-09-23T12:52:01Z","receivedAt":"2026-09-23T12:52:12Z","isPatch":false,"body":"On Tue, Sep 22, 2026 at 2:45 PM Johannes Schindelin\n wrote:\n>\n> I originally wrote this summary of the Git Contributor Summit only for my\n> own records, but since you hinted at wanting some meeting notes, figured\n> it might be interesting to other people, too. So here goes my distillation\n> of the breakout-sessions from this year's Contributors' Summit. Many of\n> these ideas still need discussion on the list; proposals below are not\n> project-wide decisions.\n\nThanks for this!\n\n\n> Git v3.0\n>\n> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in\n> December, then v2.99 and v3.0 next spring. The jump in version numbers is\n> intended to signal the approaching breaking changes. March and April were\n> both mentioned; the precise timing is not settled.\n>\n> There was agreement on releasing v2.99.1 and v3.0 together, differing only\n> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition\n> separate from another round of feature development. Nobody in the room\n> objected to Rust becoming mandatory in v3.0. (Personal note: probably\n> because Randall wasn't there, to say that NonStop support would be a\n> blocker and that Git please wait.) A v2.x LTS remains an open question,\n> with Gentoo mentioned as an interested party. (Personal note: I am still\n> advocating for an in-tree Long Term Support branch, and since Junio\n> indicated that he's less than eager to take care of that, I would love for\n> Patrick Steinhardt to be the \"LTS lieutenant\", I vaguely remember that he\n> said he'd do it if asked, and I trust his judgement, so I'd ask.)\n\nIf you are able/willing to point me towards the [relevant] Gentoo\nfolks, I'd love to chat\nwith them. It's been my distribution of choice for the last year and, while I've\nhelped some on the \"packaging Git\" side, I have to imagine the 2.x request comes\nmore from thinking about the surrounding things Git is used for (both developing\nthe system and running it, such as the 3rd-party repository syncs or live\npackage installs that use Git).\n\nAnyway, I'd like to help them out :)\n\n> Documentation\n>\n> Julia's work highlights the gap between documentation written by people\n> who know Git inside out and users who do not yet know what objects, the\n> index, or upstream mean. We need approachable learning material as well as\n> reference documentation. Both need work; keeping manpages concise does not\n> mean they cannot have better explanations and examples. (Personal note: I\n> am beyond excited that Julia, whose work I have always admired, got\n> interested in improving Git's documentation, which is in dear need of\n> being improved, mainly because it does not cater to the majority of Git\n> users out there who are unlikely to wander onto the Git mailing list,\n> ever. I just hope that old-timers who really do not need the documentation\n> nor understand the need of those who do need it show enough appreciation\n> for the fresh views and for Julia's understanding of the target audience.)\n\nDon't forget that Julia received a grant to continue working on docs!\n\nhttps://www.sovereign.tech/news/meet-the-2026-sovereign-tech-fellows\n\n> Protocol v2 for pushes\n\nDid I understand correctly from a recent discussion that v2 also requires more\n\"setup\" and is thus not easy to use for smaller \"local\" hosts? If so, making it\nmore accessible might also be nice.\n\n> I am still a fan of the idea to have more frequent, smaller, virtual\n> Contributor Summits, organized by a rotating cast. (Maybe I can get Emily to\n> host the next one.)\n\nIn other projects I've participated in, more frequent smaller check-ins have\nbeen helpful. It also feels less icky to miss one for whatever reason, since the\nnext one is not too far off!\n\n-- \nD. Ben Knoble\n"},{"id":"553063","messageId":"874ifg11zc.fsf@emacs.iotcl.com","threadId":"66362","inReplyTo":"5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de","subject":"Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2026-09-23T14:22:47Z","receivedAt":"2026-09-23T14:22:55Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n> Security mailing list and process\n\n(I decided to split up this topic into a separate mail thread)\n\n> The security list is seeing a large influx of outside reports, apparently\n> often AI-assisted or generated. Duplicates and reports outside Git's\n> security model consume triage time, while some patches have waited for\n> months. Waiting for an empty queue is not a workable release criterion: we\n> need to release the fixes we have, rather than hold them indefinitely\n> while more reports arrive.\n\nI think we agreed on that. Because we realize the influx will not stop\nany time soon.\n\n> No fixed release cadence or guaranteed response time was settled.\n>\n> Documenting Git's security model would save repeated explanations of what\n> does and does not constitute a vulnerability.\n\nThis is something I was planning to drive after the summit, so I agree.\n\n> (Personal note, not discussed at the Summit: Stolee had tried to start\n> a conversation about Git's security boundary a long time ago, but\n> nobody replied.\n\nI was not aware of that, maybe that happened before I started\nparticipating there. But I'm happy to get that conversation going again.\nI'll try to digg up that discussion.\n\n> Maybe the AI onslaught will provide enough motivation to get that\n> discussion going.)\n\nYes.\n\n> Moving non-security bugs to the public list more readily was also\n> encouraged.\n\nThat is true, but then still someone has to do the work. We're already\nlacking people to work on /real/ reports, so having people to fix bugs\nreported is also a staffing issue.\n\n> A timeout after which public discussion would be presumed OK was\n> proposed, but not agreed.\n\nI'm against that, but I don't think we need to agree on that already. We\ncan think about this after settling the other stuff.\n\n> More company staffing would help, without turning this into an obligation\n> for volunteers. Paying for dedicated help was discussed, with onboarding\n> costs a concern.\n\nAll I can say for now, we at GitLab plan to invest more people power\ninto dealing with security reports.\n\n> Using AI for triage or fixes raises confidentiality and DCO questions\n> of its own. (Personal note: There seemed to be some sentiment in the\n> room that contradicted the earlier agreed-on finding on the mailing\n> list that using AI for triaging and for investigating wasn't a\n> copyright concern and should therefore be considered permissible.)\n\nYeah, no consensus here. The concern wasn't as much copyright, but\npassing vulnerabilities to a model, making it possibly train on that\nexposing that information to who-knows-where.\n\n> The release bottleneck is not really tag automation. Merging and\n> backporting fixes, preparing advisories, and handling CVEs take work, and\n> too much of that knowledge lives in people's heads. Peff volunteered to\n> start a public discussion of the process and dig up existing resources.\n\nAs I pointed out during the conversation, I just don't know how to do\nthis.\n\n> (Personal note: I have done that merging, backporting, etc plenty of\n> times, and I don't think that it is the bottleneck, and I was rather\n> surprised to hear that it is complicated.\n\nIt's complicated, because we (or I at least) doesn't know how.\n\n> Sure, there are the expected merge conflicts when merging `maint-*`\n> branches, and running -- and fixing! -- CI on all of the tags in a\n> private repository should go without saying, but that's all craft of\n> the trade.\n\nI'd love to learn more about this.\n\n> Rather, the indecision and lack of engagement on the\n> git-security mailing list is what I see as the blocker. I'd happily\n> volunteer to juggle those branch thickets if that was truly the\n> make-or-break issue here.)\n\nI'm very grateful for that. As I mentioned (not sure that made it into\nthe notes), I'd love to shadow someone doing this to learn from. This\ncan help me get this going myself and that would distribute the load and\nknowledge among more people, for which seems to be a real need.\n\n> Microsoft's release process reportedly needs about seven weeks. There were\n> no objections in the room to proceeding without waiting for that schedule.\n> (Personal note: That release process was misrepresented, which is\n> surprising\n\nI wouldn't say this is surprising, I think most people just don't know\nthe details.\n\n> as I coordinated two or three Git for Windows security bugfix\n> releases _on the git-security list_ since the most recent Git security\n> bugfix release, it's always the same thing: release on a second Tuesday of\n> the month, three weeks before that the patches need to have settled,\n> everybody goes home with a dependable timeline.\n\nWell, thanks, that's clear.\n\nPersonally I think we can try to follow that schedule, if possible. We\ncurrently have a few patches waiting for months to be released, and\nthat's not because of the Git for Windows release schedule, but more\nbecause the lack of call to action. Those easily can get out with the\nGfW cadence.\n\nBut some other cases, like the 0day Elijah has been working on this\nmonth, I'm not sure that can wait for GfW?\n\n> It's not really that big of a deal. Testing patches, constructive\n> feedback, these are the things that are missing and therefore blocking\n> the process. I sensed a lot of finger-pointing in this discussion.\n\nI wouldn't say so, I would blame it on the lack knowledge about the\nprocess. Or maybe that's only me speaking.\n\n> I mean, I don't blame anybody for avoiding security work: it is\n> stressful and intense. The responsibility for getting things wrong is\n> enormous. I know that because I've done my share of that, probably\n> more than most in the Git project, and I will do even more in the\n> future.\n\nThat's why I'd like to learn from you.\n\n> But when I don't have the time, or the energy, I am aware that\n> I, myself, am the bottleneck; I don't need to blame others.)\n\nYou are not the bottleneck, or at least, you don't need to be the\nbottleneck, we should set up things to spread out the load.\n\nSo I would like to suggest you and me collaborate closely to get a next\nsecurity release out and then we can go from there.\n\n-- \nLaters,\nToon\n"},{"id":"553064","messageId":"871pak1151.fsf@emacs.iotcl.com","threadId":"66362","inReplyTo":"5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de","subject":"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)","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2026-09-23T14:40:58Z","receivedAt":"2026-09-23T14:41:07Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n> Documentation\n>\n> Julia's work highlights the gap between documentation written by people\n> who know Git inside out and users who do not yet know what objects, the\n> index, or upstream mean. We need approachable learning material as well as\n> reference documentation. Both need work; keeping manpages concise does not\n> mean they cannot have better explanations and examples. (Personal note: I\n> am beyond excited that Julia, whose work I have always admired, \n\nI've expressed myself multiple times as well how excited I am to have\nJulia working on this, but it cannot be expressed enough.\n\n> got interested in improving Git's documentation, which is in dear need\n> of being improved, mainly because it does not cater to the majority of\n> Git users out there who are unlikely to wander onto the Git mailing\n> list, ever. I just hope that old-timers who really do not need the\n> documentation nor understand the need of those who do need it show\n> enough appreciation for the fresh views and for Julia's understanding\n> of the target audience.)\n\nI think the old-timers do, but it takes skills to have a very deep\nunderstanding and still being able to explain things to newbies.\n\n> Discoverability matters, too. The website (https://git-scm.com/) needs\n> clearer entry points for learning Git, and existing guides are harder to\n> find than manpages. Missing subsection links are another improvement we\n> could make incrementally. (Personal note: Judging by the history of that\n> site, I do wonder whether the core Git contributors are interested in\n> helping this effort at all. For example, there are a growing number of PRs\n> suggesting to add new UIs to the growing list, but I gave up reviewing\n> them because I was the only one doing so.)\n\nI share the blame here. Some time ago I volunteered to step in to do\nmaintainance work on git-scm.com, but I haven't been devoting as much\ntime as I would like.\n\nTalking about the UI list, that's a problem which I'm not sure worth\ndiscussing here, but to folks interested, there is some context in the\nPR[1] you created.\n\n[1]: https://github.com/git/git-scm.com/pull/2179\n\n> There was support for replacing outdated material and for merging useful\n> improvements, then iterating, rather than trying to perfect everything\n> before it lands. Bringing user feedback to the list without flooding it\n> remains a challenge.\n\nIteration will be key here, and I would say some steps have been taken\nalready. Very tiny steps though.\n\nFinding a medium to gather user feedback is the problem. I think Discord\nis a better place than the mailing list (assuming that's what you mean\nby \"list\"?).\n\n> The current funding covers only 100 hours split between two people.\n> Additional project and company funding was encouraged; brian, Emily, and\n> Mark offered to explore company support. (Personal note: I had tried, back\n> when GitHub still funded my team, to start something like that, without\n> any success. To the contrary, even Git for Windows and Git Credential\n> Manager got defunded.)\n>\n> On the tooling side, using only Asciidoctor instead of maintaining both\n> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0\n> change. Distribution support and rendering differences need checking, with\n> doc-diff suggested for comparing the outputs. Patrick filed an issue\n> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now\n> maintained by Asciidoctor, and I am aware already of one change that was\n> made to the spec without adapting AsciiDoc accordingly. So the entire\n> discussion might be quite moot already.)\n>\n> Other ideas included richer diagrams for HTML while retaining text\n> versions for manpages\n\nThis feels feasible. I think brian suggested to use Open Blocks[2] and\nhave a man-page ASCII version next to /something else/.\n\n[2]: https://docs.asciidoctor.org/asciidoc/latest/blocks/open-blocks/\n\n> and privacy-respecting traffic measurements to help prioritize\n> documentation work.\n\nFor the record, we have been talking about this[3] in the past.\n\n[3]: https://github.com/git/git-scm.com/issues/2054\n\n> No diagram format was chosen\n\nYeah, that's the issue.\n\n> and caching and AI scraping complicate getting useful traffic data.\n> Mermaid was proposed, and even GraphViz. (Personal note: I added\n> support for Mermaid diagrams to https://git-scm.com/, but it turned\n> out to be too limited, so I added GraphViz support. The support code\n> for this is a bit of a beast, having a wasm version of GraphViz for\n> development, pre-rendering the diagrams as SVG and as PDF during\n> deployment of the site; it was quite a bit of fun to implement all\n> that.)\n\nThanks for that! They don't look bad on the cheat sheet[4].\n\n[4]: https://git-scm.com/cheat-sheet#combine-diverged-branches\n\n-- \nLaters,\nToon\n"},{"id":"553067","messageId":"xmqqbj9oc83t.fsf@gitster.g","threadId":"66362","inReplyTo":"871pak1151.fsf@emacs.iotcl.com","subject":"Re: Git Contributor' summit: Documentation,","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-23T15:15:02Z","receivedAt":"2026-09-23T15:15:07Z","isPatch":false,"body":"Toon Claes writes:\n\n> I've expressed myself multiple times as well how excited I am to have\n> Julia working on this, but it cannot be expressed enough.\n\n;-)\n\n>> list, ever. I just hope that old-timers who really do not need the\n>> documentation nor understand the need of those who do need it show\n>> enough appreciation for the fresh views and for Julia's understanding\n>> of the target audience.)\n>\n> I think the old-timers do, but it takes skills to have a very deep\n> understanding and still being able to explain things to newbies.\n\nNot just these two skills, but you need to know what are the points\nnew people find hard to get when they are starting, and that is the\nweakest spot for our old-timers.\n\n>> There was support for replacing outdated material and for merging useful\n>> improvements, then iterating, rather than trying to perfect everything\n>> before it lands. Bringing user feedback to the list without flooding it\n>> remains a challenge.\n>\n> Iteration will be key here, and I would say some steps have been taken\n> already. Very tiny steps though.\n\nIIRC, the view in the room was in favor of keeping and incrementally\nimproving the manual pages and reference material while rewriting\ntutorials and material on concepts from scratch. I very much agree\nwith the \"rewrite from scratch\" part, because the concepts have\nevolved and the world view have been updated even if the concepts at\nthe very core of the system may have not changed.\n"},{"id":"553134","messageId":"xmqq4iff5ml0.fsf@gitster.g","threadId":"66362","inReplyTo":"5f34a5a9-9f72-b725-666a-94798895d122@gmx.de","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T03:56:27Z","receivedAt":"2026-09-24T03:56:30Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n> Fair enough: I did ask you to confirm my summit summary. Let me separate\n> that from what I need for planning: a proposal from you as release\n> maintainer can be discussed on the list on its own merits, without waiting\n> for publication of the meeting record or claiming summit consensus.\n\nAs I wrote, after the current cycle ends at the end of this month, a\n10-12 week cycle including the end-of-year slowness would mean the\nnext cycle 2.98 will end at the end of this year. Expolation from\nthere, 2.99 will be March 2027.\n\nThe consensus in the room was that we want to use 2.99 as a signal\nthat something big is coming, so between 2.99 and 3.0 needs to be\nsome lead time for \"advertisement\". This lead time between 2.99 and\n3.0 does not have to be the usual 8-to-12-weeks full release cycle.\n\nI do not think there was a firm agreement on the date for 2.99.1 and\n3.0. Potential factors mentioned in the room included that we may\nwant to match the LTS release schedule of major distros. My\npreference would be to give a month after 2.99 to apply only\naccumulated bugfixes and nothing else and tag it as 2.99.1, which\nmeans 2.99.1 would be April 2027.\n\nThe contents of 3.0 should be identical to 2.99.1 except for the\nbreaking changes are enabled in 3.0 while they are disabled in\n2.99.1. Volunteers can run 2.99.X series indefinitely to help LTS\ndistributions.\n\nAt the release engineering level, I am very tempted to keep the\nWITH_BREAKING_CHANGES Makefile knob in 3.0 release in order to keep\nthe differences between 2.99.1 and 3.0 to absolute minimum, and then\nremove the \"dead code\" that is used when WITH_BREAKING_CHANGES is\nnot enabled from 3.X at our leasure.\n\nSo the above is what I have in mind, shaped mostly around the\nconcensus at Contributor's summit (or at least how I understand what\nthe concensus was), with my preference filling in what was not\nfirmly decided in the room.\n\nGood enough?\n"},{"id":"553136","messageId":"xmqqpky346fr.fsf@gitster.g","threadId":"66362","inReplyTo":"xmqq4iff5ml0.fsf@gitster.g","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T04:30:32Z","receivedAt":"2026-09-24T04:30:34Z","isPatch":false,"body":"Junio C Hamano writes:\n\n> As I wrote, after the current cycle ends at the end of this month, a\n> ...\n\nIt was so full of typoes and grammos because I didn't pass it thru\nspell checker as usual. Sorry about that. Here is a replacement.\n\n\n\nAs I wrote, after the current cycle ends at the end of this month, a\n10-to-12-week cycle including the end-of-year slowness would mean the\nnext cycle, 2.98, will end at the end of this year. Extrapolating\nfrom there, 2.99 will be March 2027.\n\nThe consensus in the room was that we want to use 2.99 as a signal\nthat something big is coming, so there needs to be some lead time\nbetween 2.99 and 3.0 for \"advertisement\". This lead time between\n2.99 and 3.0 does not have to be the usual 8-to-12-week full release\ncycle.\n\nI do not think there was a firm agreement on the date for 2.99.1 and\n3.0. Potential factors mentioned in the room included that we may\nwant to match the LTS release schedule of major distributions. My\npreference would be to give a month after 2.99 to apply only\naccumulated bugfixes and nothing else, and tag it as 2.99.1, which\nmeans 2.99.1 would be April 2027.\n\nThe contents of 3.0 should be identical to 2.99.1 except that\nbreaking changes are enabled in 3.0 while they are disabled in\n2.99.1. Volunteers can run the 2.99.x series indefinitely to help\nLTS distributions.\n\nAt the release engineering level, I am very tempted to keep the\nWITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to\nkeep the differences between 2.99.1 and 3.0 to an absolute minimum,\nand then remove the \"dead code\" that is used when\nWITH_BREAKING_CHANGES is not enabled from the 3.x series at our\nleisure.\n\nSo the above is what I have in mind, shaped mostly around the\nconsensus at the Contributors' Summit (or at least how I understand\nwhat the consensus was), with my preference filling in what was not\nfirmly decided in the room.\n\n\n"},{"id":"553175","messageId":"306e7563-c356-dc59-c14a-ff8e99a948ae@gmx.de","threadId":"66362","inReplyTo":"xmqqpky346fr.fsf@gitster.g","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-24T12:29:01Z","receivedAt":"2026-09-24T12:29:06Z","isPatch":false,"body":"Hi Junio,\n\nOn Wed, 23 Sep 2026, Junio C Hamano wrote:\n\n> As I wrote, after the current cycle ends at the end of this month, a\n> 10-to-12-week cycle including the end-of-year slowness would mean the\n> next cycle, 2.98, will end at the end of this year. Extrapolating\n> from there, 2.99 will be March 2027.\n> \n> The consensus in the room was that we want to use 2.99 as a signal\n> that something big is coming, so there needs to be some lead time\n> between 2.99 and 3.0 for \"advertisement\". This lead time between\n> 2.99 and 3.0 does not have to be the usual 8-to-12-week full release\n> cycle.\n> \n> I do not think there was a firm agreement on the date for 2.99.1 and\n> 3.0. Potential factors mentioned in the room included that we may\n> want to match the LTS release schedule of major distributions. My\n> preference would be to give a month after 2.99 to apply only\n> accumulated bugfixes and nothing else, and tag it as 2.99.1, which\n> means 2.99.1 would be April 2027.\n> \n> The contents of 3.0 should be identical to 2.99.1 except that\n> breaking changes are enabled in 3.0 while they are disabled in\n> 2.99.1. Volunteers can run the 2.99.x series indefinitely to help\n> LTS distributions.\n> \n> At the release engineering level, I am very tempted to keep the\n> WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to\n> keep the differences between 2.99.1 and 3.0 to an absolute minimum,\n> and then remove the \"dead code\" that is used when\n> WITH_BREAKING_CHANGES is not enabled from the 3.x series at our\n> leisure.\n> \n> So the above is what I have in mind, shaped mostly around the\n> consensus at the Contributors' Summit (or at least how I understand\n> what the consensus was), with my preference filling in what was not\n> firmly decided in the room.\n\nThank you so much! This will make it much easier for me to plan out the\nGit for Windows roadmap, such as switching to Rust-based builds and\nintegrating Git Credential Manager v3.0.\n\nCiao,\nJohannes\n"},{"id":"553177","messageId":"682ca568-ba3e-1102-ec21-03dd4aee2e14@gmx.de","threadId":"66362","inReplyTo":"c12b9da1-b679-43e5-9485-2cedeb1dc613@gmail.com","subject":"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)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-24T12:31:03Z","receivedAt":"2026-09-24T12:31:05Z","isPatch":false,"body":"Hi Daniele,\n\nOn Wed, 23 Sep 2026, Daniele Sassoli wrote:\n\n> Thanks so much for this summary, I didn't participate at the contributor\n> summit as I was leading one of the breakout sessions in the morning and\n> had a plane to catch in the afternoon, so I'm very grateful of your\n> summary.\n\nI'm glad it was helpful!\n\n> On 22/09/2026 19:44, Johannes Schindelin wrote:\n>\n> [... snip ...]\n> > Pluggable object database\n> >\n> > Patrick's pluggable object database is working, but it is not\n> > complete: commit-graph and multi-pack-index integration are still\n> > outstanding, and a repository extension is planned. (Personal note: It\n> > might be interesting to see whether implementing a storage backend is\n> > easier in core Git or in another Git-compatible implementation. JGit\n> > should be a natural target, having originated within BigTable-sized\n> > constraints, i.e. a different storage system, but funding seems to\n> > have dried up, there's not even SHA-256 support, so JGit might not be\n> > as hackable as it once was.)\n>\n> Pluggable backend implementations for JGit have been possible for quite\n> some time, although, admittedly, I don't think any made it to\n> production. Maybe at the time when this was introduced(16 years ago!!)\n> by Shawn[1] in JGit it wasn't fashionable yet and so the project was\n> never carried forward. I know Luca submitted a talk for the Gerrit User\n> Summit to present a Cassandra back-end, for which I can see conversation\n> started 10 years ago[2].\n> \n> Regarding JGit support's for SHA256, I know some corporations have had\n> interest in sponsoring this work and have discussed potentially\n> implementing together it with GerritForge, but, as far as I know, work\n> isn't ongoing yet. JGit is still very much developed and kept up to date\n> with great effort from the community, so I believe it to still be as\n> hackable as it was, there just hasn't been enough interest for SHA-256\n> yet, which I agree is a shame, hopefully in the near future this gets\n> remediated.\n> \n> [1] https://github.com/spearce/jgit_cassandra\n> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE\n\nI'm glad to hear that JGit isn't stalled, even though I doubt that the\nSHA-256 support could be done without any corporate support.\n\nCiao,\nJohannes\n"},{"id":"553178","messageId":"9dd7427b-2130-a936-5a90-24f7c8fd719f@gmx.de","threadId":"66362","inReplyTo":"874ifg11zc.fsf@emacs.iotcl.com","subject":"Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-09-24T12:38:33Z","receivedAt":"2026-09-24T12:38:36Z","isPatch":false,"body":"Hi Toon,\n\nOn Wed, 23 Sep 2026, Toon Claes wrote:\n\n> Johannes Schindelin writes:\n> \n> > Security mailing list and process\n> >\n> > [...]\n> >\n> > Microsoft's release process reportedly needs about seven weeks. There\n> > were no objections in the room to proceeding without waiting for that\n> > schedule. (Personal note: That release process was misrepresented,\n> > which is surprising\n> \n> I wouldn't say this is surprising, I think most people just don't know\n> the details.\n> \n> > as I coordinated two or three Git for Windows security bugfix releases\n> > _on the git-security list_ since the most recent Git security bugfix\n> > release, it's always the same thing: release on a second Tuesday of\n> > the month, three weeks before that the patches need to have settled,\n> > everybody goes home with a dependable timeline.\n> \n> Well, thanks, that's clear.\n> \n> Personally I think we can try to follow that schedule, if possible. We\n> currently have a few patches waiting for months to be released, and\n> that's not because of the Git for Windows release schedule, but more\n> because the lack of call to action. Those easily can get out with the\n> GfW cadence.\n\nI'm glad that you agree that Patch Tuesday isn't all _that_ much of a\nfriction point, this will allow some of my colleagues to relax visibly.\n\n> [...]\n> \n> So I would like to suggest you and me collaborate closely to get a next\n> security release out and then we can go from there.\n\nExcellent! Let's continue this conversation in a more private setting ;-)\n\nCiao,\nJohannes\n"},{"id":"553210","messageId":"xmqqy0cq37ql.fsf@gitster.g","threadId":"66362","inReplyTo":"306e7563-c356-dc59-c14a-ff8e99a948ae@gmx.de","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-24T17:00:02Z","receivedAt":"2026-09-24T17:00:06Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n>> So the above is what I have in mind, shaped mostly around the\n>> consensus at the Contributors' Summit (or at least how I understand\n>> what the consensus was), with my preference filling in what was not\n>> firmly decided in the room.\n>\n> Thank you so much! This will make it much easier for me to plan out the\n> Git for Windows roadmap, such as switching to Rust-based builds and\n> integrating Git Credential Manager v3.0.\n\nNote that I consider it risky to treat the timeline as already set\nin stone.\n\nIn particular, if we find that 2.99 needs a longer stabilization\neffort, we may need to slip 2.99.1 by a month or follow it with\n2.99.2 or even 2.99.3, and 3.0 may have to coincide with one of\nthese later maintenance releases. Anything beyond the end of this\nyear is in \"we do not yet know and we will play it by ear when the\ntime comes\" territory.\n\nThanks.\n"},{"id":"553219","messageId":"d1ad4da9-e5b6-41c8-8049-0d8ac012a1e2@ramsayjones.plus.com","threadId":"66362","inReplyTo":"xmqqpky346fr.fsf@gitster.g","subject":"Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2026-09-24T18:08:53Z","receivedAt":"2026-09-24T18:12:03Z","isPatch":false,"body":"\n\nOn 24/09/2026 5:30 am, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n[snip]\n> As I wrote, after the current cycle ends at the end of this month, a\n> 10-to-12-week cycle including the end-of-year slowness would mean the\n> next cycle, 2.98, will end at the end of this year. Extrapolating\n> from there, 2.99 will be March 2027.\n> \n> The consensus in the room was that we want to use 2.99 as a signal\n> that something big is coming, so there needs to be some lead time\n> between 2.99 and 3.0 for \"advertisement\". This lead time between\n> 2.99 and 3.0 does not have to be the usual 8-to-12-week full release\n> cycle.\n> \n> I do not think there was a firm agreement on the date for 2.99.1 and\n> 3.0. Potential factors mentioned in the room included that we may\n> want to match the LTS release schedule of major distributions. My\n> preference would be to give a month after 2.99 to apply only\n> accumulated bugfixes and nothing else, and tag it as 2.99.1, which\n> means 2.99.1 would be April 2027.\n> \n> The contents of 3.0 should be identical to 2.99.1 except that\n> breaking changes are enabled in 3.0 while they are disabled in\n> 2.99.1. Volunteers can run the 2.99.x series indefinitely to help\n> LTS distributions.\n> \n> At the release engineering level, I am very tempted to keep the\n> WITH_BREAKING_CHANGES Makefile knob in the 3.0 release in order to\n> keep the differences between 2.99.1 and 3.0 to an absolute minimum,\n> and then remove the \"dead code\" that is used when\n> WITH_BREAKING_CHANGES is not enabled from the 3.x series at our\n> leisure.\n> \n> So the above is what I have in mind, shaped mostly around the\n> consensus at the Contributors' Summit (or at least how I understand\n> what the consensus was), with my preference filling in what was not\n> firmly decided in the room.\n\n\nBack in January, on the cygwin-announce list[1], an experimental rust package\nwas announced. This package was marked experimental and unmaintained in the\ncygwin setup program. I was hoping for a more 'official' package to emerge\nbefore trying it out on git. (the package was version 1.91.0 of rust built\nfrom a source tarball). However, there has been no sign of a formal supported\n(test or production) package since then (there is still time, of course). ;)\n\nAnyway, this thread prompted me to try the experimental package:\n\n $ vim config.mak # comment out NO_RUST\n $ cat config.mak\n DEFAULT_TEST_TARGET=prove\n GIT_PROVE_OPTS=--timer -j8\n #NO_RUST=1\n NO_DC_SHA1_SUBMODULE=NoThanks\n DEVELOPER=1\n $ \n\nHaving fetched today, the 'master' branch @0f8e75abeb is v2.56.0-rc2 with\nthe branch 'en/no-amend-during-conflicts' reverted.\n \n $ make >out1 2>&1\n $ ./git version\n git version 2.56.0.rc2.1.g0f8e75abeb\n $ git describe\n v2.56.0-rc2-1-g0f8e75abeb\n $ diff out out1\n 1c1\n < GIT_VERSION=2.56.0.rc2\n ---\n > GIT_VERSION=2.56.0.rc2.1.g0f8e75abeb\n 277d276\n < CC varint.o\n 308a308\n > CARGO target/release/libgitcore.a\n $ \n\nThe 'out' file is yesterdays build of v2.56.0-rc2. (Similarly, the 'sp-out',\n'sc' and 'hcout' files record output for v2.56.0-rc2).\n\n $ make sparse >sp-out1 2>&1\n $ diff sp-out sp-out1\n 268d267\n < SP varint.c\n $ \n\n $ ./static-check.pl >sc1\n $ diff sc sc1\n $ \n\n $ make -k hdr-check >hcout1 2>&1\n $ diff hcout hcout1\n $ \n\n $ . ../git-test-setup\n $ env | grep TEST\n TEST_NO_MALLOC_CHECK=yes\n GIT_TEST_CHAIN_LINT=0\n $ make test >test-out-2-56-rc2-1 2>&1\n $ tail -n 13 test-out-2-56-rc2-1\n Test Summary Report\n -------------------\n unit-tests/bin/unit-tests.exe (Wstat: 256 (exited 1) Tests: 261 Failed: 1)\n Failed test: 254\n Non-zero exit status: 1\n t9904-url-parse.sh (Wstat: 256 (exited 1) Tests: 53 Failed: 4)\n Failed tests: 39, 42-43, 47\n Non-zero exit status: 1\n Files=1060, Tests=33592, 3519 wallclock secs (42.61 usr 141.30 sys + 9056.74 cusr 12680.95 csys = 21921.60 CPU)\n Result: FAIL\n make[1]: *** [Makefile:82: prove] Error 1\n make[1]: Leaving directory '/home/ramsay/git/t'\n make: *** [Makefile:3424: test] Error 2\n $\n\nDespite the failure, this shows exactly the same failures as v2.56.0-rc2.\n\nSo, this doesn't stress the rust compiler very much, but I guess it is\nslightly encouraging! I suppose Brian has plenty of rust code in a branch\nsomewhere that could be tested ...\n\nUnfortunately, I am just about (in a few hours) to go into hospital for a\nsurgical procedure, so I will be AWOL for some time yet, ...\n\nATB,\nRamsay Jones\n\n[1] https://sourceware.org/pipermail/cygwin-announce/2026-January/012823.html\n\n\n\n\n"},{"id":"553271","messageId":"0A5DE74C-053E-4732-B7F2-174EA198539F@gmail.com","threadId":"66362","inReplyTo":"c12b9da1-b679-43e5-9485-2cedeb1dc613@gmail.com","subject":"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)","fromName":"Luca Milanesio","fromEmail":"luca.milanesio@gmail.com","sentAt":"2026-09-25T09:53:19Z","receivedAt":"2026-09-25T09:53:34Z","isPatch":false,"body":"Thanks Johannes for the detailed summary,\n\nSee below some additions on the storage backend in JGit below.\n\n> On 23 Sep 2026, at 12:55, Daniele Sassoli wrote:\n> \n> Hi Johannes,\n> \n> Thanks so much for this summary, I didn't participate at the contributor summit\n> as I was leading one of the breakout sessions in the morning and had a plane to\n> catch in the afternoon, so I'm very grateful of your summary.\n> \n> On 22/09/2026 19:44, Johannes Schindelin wrote:\n>> Hi Junio,\n>> \n>> On Tue, 22 Sep 2026, Junio C Hamano wrote:\n>> \n>>> Johannes Schindelin writes:\n>>> \n>>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:\n>>>> \n>>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before\n>>>>> the final Git 2.56 release, but otherwise I do not expect any new\n>>>>> feature topics to be ready before the final, so most of the\n>>>>> in-flight topics will stay cooking in 'next' until then. As\n>>>>> discussed at the Git Contributors' Summit, the version after the\n>>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this\n>>>>> year.\n>>>> Would you say that the following is an accurate characterization of the\n>>>> timeline, so that people who need to plan dependent projects can rely on\n>>>> it?\n>>> My outline was deliberately limited up to end of this year as I am\n>>> hesitant to say beyond that point before the meeting notes are made\n>>> public.\n>> I originally wrote this summary of the Git Contributor Summit only for my\n>> own records, but since you hinted at wanting some meeting notes, figured\n>> it might be interesting to other people, too. So here goes my distillation\n>> of the breakout-sessions from this year's Contributors' Summit. Many of\n>> these ideas still need discussion on the list; proposals below are not\n>> project-wide decisions.\n>> \n>> Security mailing list and process\n>> \n>> The security list is seeing a large influx of outside reports, apparently\n>> often AI-assisted or generated. Duplicates and reports outside Git's\n>> security model consume triage time, while some patches have waited for\n>> months. Waiting for an empty queue is not a workable release criterion: we\n>> need to release the fixes we have, rather than hold them indefinitely\n>> while more reports arrive. No fixed release cadence or guaranteed response\n>> time was settled.\n>> \n>> Documenting Git's security model would save repeated explanations of what\n>> does and does not constitute a vulnerability. (Personal note, not\n>> discussed at the Summit: Stolee had tried to start a conversation about\n>> Git's security boundary a long time ago, but nobody replied. Maybe the AI\n>> onslaught will provide enough motivation to get that discussion going.)\n>> Moving non-security bugs to the public list more readily was also\n>> encouraged. A timeout after which public discussion would be presumed OK\n>> was proposed, but not agreed.\n>> \n>> More company staffing would help, without turning this into an obligation\n>> for volunteers. Paying for dedicated help was discussed, with onboarding\n>> costs a concern. Using AI for triage or fixes raises confidentiality and\n>> DCO questions of its own. (Personal note: There seemed to be some\n>> sentiment in the room that contradicted the earlier agreed-on finding on\n>> the mailing list that using AI for triaging and for investigating wasn't a\n>> copyright concern and should therefore be considered permissible.)\n>> \n>> The release bottleneck is not really tag automation. Merging and\n>> backporting fixes, preparing advisories, and handling CVEs take work, and\n>> too much of that knowledge lives in people's heads. Peff volunteered to\n>> start a public discussion of the process and dig up existing resources.\n>> (Personal note: I have done that merging, backporting, etc plenty of\n>> times, and I don't think that it is the bottleneck, and I was rather\n>> surprised to hear that it is complicated. Sure, there are the expected\n>> merge conflicts when merging `maint-*` branches, and running -- and\n>> fixing! -- CI on all of the tags in a private repository should go without\n>> saying, but that's all craft of the trade. Rather, the indecision and lack\n>> of engagement on the git-security mailing list is what I see as the\n>> blocker. I'd happily volunteer to juggle those branch thickets if that was\n>> truly the make-or-break issue here.)\n>> \n>> Microsoft's release process reportedly needs about seven weeks. There were\n>> no objections in the room to proceeding without waiting for that schedule.\n>> (Personal note: That release process was misrepresented, which is\n>> surprising, as I coordinated two or three Git for Windows security bugfix\n>> releases _on the git-security list_ since the most recent Git security\n>> bugfix release, it's always the same thing: release on a second Tuesday of\n>> the month, three weeks before that the patches need to have settled,\n>> everybody goes home with a dependable timeline. It's not really that big\n>> of a deal. Testing patches, constructive feedback, these are the things\n>> that are missing and therefore blocking the process. I sensed a lot of\n>> finger-pointing in this discussion. I mean, I don't blame anybody for\n>> avoiding security work: it is stressful and intense. The responsibility\n>> for getting things wrong is enormous. I know that because I've done my\n>> share of that, probably more than most in the Git project, and I will do\n>> even more in the future. But when I don't have the time, or the energy, I\n>> am aware that I, myself, am the bottleneck; I don't need to blame others.)\n>> \n>> Git v3.0\n>> \n>> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in\n>> December, then v2.99 and v3.0 next spring. The jump in version numbers is\n>> intended to signal the approaching breaking changes. March and April were\n>> both mentioned; the precise timing is not settled.\n>> \n>> There was agreement on releasing v2.99.1 and v3.0 together, differing only\n>> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition\n>> separate from another round of feature development. Nobody in the room\n>> objected to Rust becoming mandatory in v3.0. (Personal note: probably\n>> because Randall wasn't there, to say that NonStop support would be a\n>> blocker and that Git please wait.) A v2.x LTS remains an open question,\n>> with Gentoo mentioned as an interested party. (Personal note: I am still\n>> advocating for an in-tree Long Term Support branch, and since Junio\n>> indicated that he's less than eager to take care of that, I would love for\n>> Patrick Steinhardt to be the \"LTS lieutenant\", I vaguely remember that he\n>> said he'd do it if asked, and I trust his judgement, so I'd ask.)\n>> \n>> SHA-256 support across the ecosystem had been a blocker. GitHub reported\n>> experimental support, with general availability expected around November.\n>> GitLab already had public, non-experimental support, and libgit2 supports\n>> it, too. JGit remains a gap; Google was not planning to fund that work.\n>> \n>> The SHA-1/SHA-256 interoperability work, including historical tags, was\n>> reported to be implemented but not yet sent to the list. (Personal note: I\n>> think that the room seriously \"mis-underestimated\" the real-world impact\n>> of this. The code is not even on the Git mailing list, and the\n>> ramifications of not having a robust plan how to deal with partial clones\n>> or submodules or even signed tags strikes me as a dealbreaker. I would not\n>> be surprised if the decision to enforce SHA-256 as default would have to\n>> be revisited before v3.0, and possibly overturned.)\n>> \n>> Documentation\n>> \n>> Julia's work highlights the gap between documentation written by people\n>> who know Git inside out and users who do not yet know what objects, the\n>> index, or upstream mean. We need approachable learning material as well as\n>> reference documentation. Both need work; keeping manpages concise does not\n>> mean they cannot have better explanations and examples. (Personal note: I\n>> am beyond excited that Julia, whose work I have always admired, got\n>> interested in improving Git's documentation, which is in dear need of\n>> being improved, mainly because it does not cater to the majority of Git\n>> users out there who are unlikely to wander onto the Git mailing list,\n>> ever. I just hope that old-timers who really do not need the documentation\n>> nor understand the need of those who do need it show enough appreciation\n>> for the fresh views and for Julia's understanding of the target audience.)\n>> \n>> Discoverability matters, too. The website (https://git-scm.com/) needs\n>> clearer entry points for learning Git, and existing guides are harder to\n>> find than manpages. Missing subsection links are another improvement we\n>> could make incrementally. (Personal note: Judging by the history of that\n>> site, I do wonder whether the core Git contributors are interested in\n>> helping this effort at all. For example, there are a growing number of PRs\n>> suggesting to add new UIs to the growing list, but I gave up reviewing\n>> them because I was the only one doing so.)\n>> \n>> There was support for replacing outdated material and for merging useful\n>> improvements, then iterating, rather than trying to perfect everything\n>> before it lands. Bringing user feedback to the list without flooding it\n>> remains a challenge.\n>> \n>> The current funding covers only 100 hours split between two people.\n>> Additional project and company funding was encouraged; brian, Emily, and\n>> Mark offered to explore company support. (Personal note: I had tried, back\n>> when GitHub still funded my team, to start something like that, without\n>> any success. To the contrary, even Git for Windows and Git Credential\n>> Manager got defunded.)\n>> \n>> On the tooling side, using only Asciidoctor instead of maintaining both\n>> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0\n>> change. Distribution support and rendering differences need checking, with\n>> doc-diff suggested for comparing the outputs. Patrick filed an issue\n>> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now\n>> maintained by Asciidoctor, and I am aware already of one change that was\n>> made to the spec without adapting AsciiDoc accordingly. So the entire\n>> discussion might be quite moot already.)\n>> \n>> Other ideas included richer diagrams for HTML while retaining text\n>> versions for manpages, and privacy-respecting traffic measurements to help\n>> prioritize documentation work. No diagram format was chosen, and caching\n>> and AI scraping complicate getting useful traffic data. Mermaid was\n>> proposed, and even GraphViz. (Personal note: I added support for Mermaid\n>> diagrams to https://git-scm.com/, but it turned out to be too limited, so\n>> I added GraphViz support. The support code for this is a bit of a beast,\n>> having a wasm version of GraphViz for development, pre-rendering the\n>> diagrams as SVG and as PDF during deployment of the site; it was quite a\n>> bit of fun to implement all that.)\n>> \n>> Outreachy sponsoring\n>> \n>> The goal is to support three interns in the round starting in early\n>> December, at $10,000 each. The corporate sponsorship previously provided\n>> by GitLab and GitHub has dried up, leaving Git itself to pay. There are\n>> company contacts to follow up with; Emily offered to ask Google's OSPO,\n>> without high expectations. No new sponsorship commitments were made.\n>> (Personal note: I don't think that these internships provide enough\n>> publicity to give companies much of an incentive to fund this. Which I\n>> find a bit of a shame, Outreachy in particular does a lot of important,\n>> good work, and if I wasn't so constantly overworked, I would want to\n>> mentor again; I always found it rewarding, even if I hold myself to a\n>> quite high bar which is quite draining.)\n>> \n>> A related point for Git Merge 2027: announcing the location early would\n>> help Outreachy and GSoC interns plan attendance. No location was selected.\n>> \n>> Pluggable object database\n>> \n>> Patrick's pluggable object database is working, but it is not complete:\n>> commit-graph and multi-pack-index integration are still outstanding, and a\n>> repository extension is planned. (Personal note: It might be interesting\n>> to see whether implementing a storage backend is easier in core Git or in\n>> another Git-compatible implementation. JGit should be a natural target,\n>> having originated within BigTable-sized constraints, i.e. a different\n>> storage system, but funding seems to have dried up, there's not even\n>> SHA-256 support, so JGit might not be as hackable as it once was.)\n> Pluggable backend implementations for JGit have been possible for quite some\n> time, although, admittedly, I don't think any made it to production.\n\n\nI'd like to provide some context here, as several pluggable JGit storage\nimplementations are actually running in highly demanding production\nenvironments today.\n\nFirst, the Git servers at Google (including gerrit.googlesource.com) are\npowered by a custom, pluggable JGit storage backend built on top of Google's\ninternal data-center storage. While the backend implementation itself is\nproprietary, it relies entirely on the exact same JGit classes and pluggable\ninterfaces available in the open-source project. It has been operating\nsmoothly at a massive scale for over a decade.\n\nSecond, there is a highly successful open-source implementation focusing on the\nref-db layer of Git storage. Developed by GerritForge over six years ago and\ndonated to the AOSP project (see the GitHub mirror at [3]), this backend is\nused daily in several large, multi-site Gerrit deployments worldwide. It allows\nfor globally consistent updates of Git repository refs across distributed\nremote sites.\n\nThird, regarding the implementation mentioned by Dani [2]: while it captured\nattention 10 years ago, without seeing immediate adoption, I suspect the timing simply\npreceded the current appetite for AI-generated code. The demand is entirely\ndifferent now. The architectural foundation Google built into JGit over 16\nyears ago is perfectly positioned to support these kinds of modern innovations.\n\nIt is genuinely exciting to see the core Git project moving in this same\ndirection with Patrick's work. Pluggability has always been a core strength of\nJGit's design, and seeing the broader ecosystem embrace this abstraction is a\nhuge win for all of us.\n\n[3] (github.com/GerritCodeReview/modules_global-refdb)\n\nLuca\n\n> Maybe at\n> the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it wasn't\n> fashionable yet and so the project was never carried forward. I know Luca\n> submitted a talk for the Gerrit User Summit to present a Cassandra back-end, for\n> which I can see conversation started 10 years ago[2].\n> \n> Regarding JGit support's for SHA256, I know some corporations have had interest\n> in sponsoring this work and have discussed potentially implementing together it\n> with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is still\n> very much developed and kept up to date with great effort from the community, so\n> I believe it to still be as hackable as it was, there just hasn't been enough\n> interest for SHA-256 yet, which I agree is a shame, hopefully in the near future\n> this gets remediated.\n> \n> [1] https://github.com/spearce/jgit_cassandra\n> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE\n>> \n>> Content-defined chunking prompted an important distinction between\n>> changing how objects are stored and changing the logical object model.\n>> Starting at the storage layer would let us preserve existing blob OIDs\n>> rather than require ecosystem-wide changes. A new pack/index format could\n>> provide another representation of the same object, much as deltas do\n>> today. No particular representation was agreed. (Personal note: It is\n>> curious to me why nobody tought about inventing a \"meta blob\", i.e. an\n>> object much like a tree object, except that it stitches together a larger\n>> blob. This would allow for the content-defined chunking that `rsync`\n>> already championed, way before Git was born! It would have allowed a Git\n>> native large file support worth writing home about, and could have\n>> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would\n>> not have had to be invented, and it would have allowed game development to\n>> move to Git. I can only imagine that the time it would cost to get even\n>> the first patches of this into core Git would be seen as prohibitive by\n>> any company who may have considered the effort.)\n>> \n>> There is also an API question: does a backend seeing only object content\n>> have enough context to make good storage and delta choices, or should it\n>> receive richer information? More searchable tree storage and a Git \"commit\n>> cloud\" were other possibilities raised, not committed plans. (Personal\n>> note: At a previous GitMerge, Facebook presented their work, see e.g.\n>> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,\n>> which includes separating actual storage from transport. That is, already\n>> at push time, derived metadata is computed in async jobs which provide\n>> several potential deltas ready-to-go when a client clones or fetches. They\n>> reported clones with regular Git clients that are twice as fast, just\n>> because the server doesn't need to spend much compute on the data it\n>> sends. So there is a lot to be learned out there already.)\n>> \n>> AI\n>> \n>> The current SubmittingPatches policy is rooted in DCO certification and\n>> advice from SFC lawyers. The unresolved question is whether, and to what\n>> extent, contributors can certify AI-generated code. There was substantial\n>> disagreement about acceptable use, provenance and legal risks, community\n>> trust, review burden, and whether the current caution excludes useful\n>> tools. No policy change was agreed. (Personal note: You'd think that the\n>> opinion of lawyers is taken at face value, but no, it seems that some core\n>> Git contributors seem to disagree with the lawyers in favor of their own\n>> opinion...)\n>> \n>> Several participants found language and proofreading assistance useful. A\n>> particular concern was submissions where the human does little more than\n>> relay agent output, leaving reviewers to deal with the consequences. The\n>> influx of poor GSoC contributions was one example. Attribution such as\n>> Assisted-by was suggested to make tool use clearer, but attribution alone\n>> does not answer the quality or DCO questions. (Personal note: my precedent\n>> of \"Assisted-by\" was called out as helpful, and I do think it is. I make a\n>> difference between AI-generated and AI-assisted. I'm not a fast typer, so\n>> I benefit a lot from being able to tell an LLM to please refactor out\n>> these four lines with the appropriate signature. There's not much\n>> creativity in there. I also like to let AI present me the call graphs for\n>> certain code locations, because due to the choice of C, which thanks to\n>> the C preprocessor is not easy to analyze statically, there are no\n>> competent tools other than LLMs that I can use for the task. I was highly\n>> surprised, though, to see how much enmity against AI in general was\n>> voiced, not by many, but many, many times, and how that contrasts with the\n>> Linux project which I hitherto had not considered to be as particularly\n>> open to modern practices.)\n>> \n>> brian and Taylor agreed to put differing policy proposals on the list. The\n>> suggested process is to have alternatives examined by SFC counsel, make\n>> the risks clear, and then consider a vote. Emily volunteered to organize\n>> the voting procedure. Eligibility and the details remain open; Junio's\n>> authority as maintainer remains central. (Personal note: Since Taylor\n>> works for OpenAI now, I was not surprised by his stance, but brian works\n>> at GitHub, home of GitHub Copilot, and I am not sure how favorable their\n>> employer would look at their semi-public utterings about AI...)\n>> \n>> Protocol v2 for pushes\n>> \n>> There are concrete use cases now: repositories with millions of refs,\n>> including a reported 896 MB ref advertisement. Reftable improves ref\n>> update throughput, but does not by itself solve the advertisement problem.\n>> Nobody objected to push protocol v2, and the fetch-v2 infrastructure\n>> already provides much of the foundation.\n>> \n>> The discussion covered advertising fewer refs, letting clients identify\n>> useful branches, and replacing large advertisements with a few rounds of\n>> push negotiation. Negotiation results could also help optimize the\n>> server's connectivity checks. Some improvements might be possible in the\n>> existing protocol before introducing v2.\n>> \n>> We need to measure the tradeoffs rather than assume fewer bytes means\n>> faster pushes. One example involved a shallow push taking 35 seconds\n>> instead of two because of work to minimize the transfer. Shallow\n>> boundaries and unrelated histories complicate the proposed heuristics.\n>> \n>> SHA-256 interoperability is another reason to want push v2: the current\n>> push protocol requires using the server's primary hash algorithm.\n>> Negotiation could make that more flexible.\n>> \n>> Forge replication to thousands of mirrors would benefit from finding out\n>> cheaply whether refs have changed, rather than downloading full\n>> advertisements from every target. Checksums, ETag-like values, and\n>> reftable generation numbers were discussed, with concurrent updates\n>> complicating the picture.\n>> \n>> Compact or compressed advertisements are also worth exploring and\n>> benchmarking, possibly reusing reftable's format. That does not mean\n>> sending the server's actual reftable, including hidden refs. There are\n>> several promising directions here, but no final design yet.\n>> \n>> Some breakout sessions were planned, but apparently had to be cut.\n>> \n>> Personal notes: I wasn't present for all of the sessions, in the afternoon\n>> I had other commitments; Therefore these notes (which AI assisted me in\n>> distilling) came partially from what I dictated and partially from the\n>> shared Google Document in which a few volunteers gracefully wrote notes. I\n>> found it challenging to connect as a remote participant. The link to the\n>> Google Meet, as well as control over the lobby thereof, seems to have been\n>> restricted to at most a few people, which might have contributed to the\n>> long waiting time before I was allowed in, and it definitely contributed\n>> to my comments not reaching the discussion in time to have an impact. I\n>> would have loved for Junio or the other two brave souls who also\n>> participated remotedly to have had more \"air time\". I am still a fan of\n>> the idea to have more frequent, smaller, virtual Contributor Summits,\n>> organized by a rotating cast. (Maybe I can get Emily to host the next\n>> one.) I was very happy that Junio was participating, as he _is_ the\n>> project lead, and in past Contributor Summits decisions were taken without\n>> him, which I found odd. Timing was really challenging for him, though, it\n>> was way past midnight for him. I'm all the more grateful that he\n>> did participate.\n>> \n>> Final remark: This summary is obviously biased. I lightly edited it to\n>> separate better between my personal views and a hopefully unbiased account\n>> of what was discussed, and how, and by who. Nevertheless, I am but human.\n>> As a consequence, I would be delighted if other participants would share\n>> their summaries, so that my bias can be balanced out.\n>> \n>> Ciao,\n>> Johannes\n> \n\n"}]}