What's cooking in git.git (Aug 2025, #01; Sun, 3)
Here are the topics that have been cooking in my tree. Commits prefixed with '+' are in 'next' (being in 'next' is a sign that a topic is stable enough to be used and are candidate to be in a future release). Commits prefixed with '-' are only in 'seen', and aren't considered "accepted" at all and may be annotated with an URL to a message that raises issues but they are no means exhaustive. A topic without enough support may be discarded after a long period of no activity (of course they can be resubmit when new interests arise).
Git 2.51-rc0 preview release is planned to happen tomorrow, but no promises.
Copies of the source code to Git live in many repositories, and the following is a list of the ones I push into or their mirrors. Some repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/ git://repo.or.cz/alt-git.git/ https://kernel.googlesource.com/pub/scm/git/git/ https://github.com/git/git/ https://gitlab.com/git-scm/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format are not sources, they are published in these repositories for convenience (replace "htmldocs" with "manpages" for the manual pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[Graduated to 'master']
* ag/imap-send-list-folders-doc (2025-07-22) 1 commit
(merged to 'next' on 2025-07-24 at d7db48890b)
+ docs: explain how to use git imap-send --list command to get a list of available folders
Document recently added "git imap-send --list" with an example.
source: <[email protected]>
* cb/meson-avoid-broken-macos-pcre2 (2025-07-18) 1 commit (merged to 'next' on 2025-07-24 at b8cea692a4)
+ meson: work around broken system PCRE2 dependency in macOS
Build fix for macOS.
source: <[email protected]>
* hl/test-helper-fd-close (2025-07-23) 4 commits (merged to 'next' on 2025-07-28 at 1e63fd84fe)
+ test-delta: close output descriptor after use
+ test-delta: use strbufs to hold input files
+ test-delta: handle errors with die()
+ t/helper/test-truncate: close file descriptor after truncation
A few file descriptors left unclosed upon program completion in a few test helper programs are now closed.
source: <[email protected]>
source: <[email protected]>
* jc/ci-print-test-failures-fix (2025-07-16) 1 commit (merged to 'next' on 2025-07-24 at a1924c981b)
+ ci: allow github-actions print test failures again
CI fix.
source: <[email protected]>
* jc/do-not-scan-argv-without-parsing (2025-07-21) 1 commit (merged to 'next' on 2025-07-23 at 8e3db5dcca)
+ rev-list: update a NEEDSWORK comment
Update a hard-to-read in-code NEEDSWORK comment.
source: <[email protected]>
* jc/document-test-balloons-in-flight (2025-07-23) 1 commit (merged to 'next' on 2025-07-24 at c239410df9)
+ CodingGuidelines: document test balloons in flight
To help our developers, document what C99 language features are being considered for adoption, in addition to what past experiments have already decided.
source: <[email protected]>
* jc/rev-list-info-cleanup (2025-07-18) 1 commit (merged to 'next' on 2025-07-23 at 09282d051a)
+ rev-list: make "struct rev_list_info" static to the only user
Move structure definition from unrelated header file to where it belongs.
source: <[email protected]>
* jk/revision-no-early-output (2025-07-19) 1 commit (merged to 'next' on 2025-07-23 at cfc20b3eb9)
+ revision: drop early output option
Remove unsupported, unused, and unsupportable old option from "git log".
source: <[email protected]>
* jk/unleak-reflog-expire-entry (2025-07-22) 1 commit (merged to 'next' on 2025-07-23 at 1663299f09)
+ reflog: close leak of reflog expire entry
Leakfix.
source: <20250722-jk-fix-leak-reflog-expire-config-v4-1-b65a83551020@gmail.com>
* kn/for-each-ref-skip (2025-07-24) 6 commits (merged to 'next' on 2025-07-28 at c721b90bdc)
+ ref-cache: set prefix_state when seeking (merged to 'next' on 2025-07-15 at 4ea3c74afd)
+ for-each-ref: introduce a '--start-after' option
+ ref-filter: remove unnecessary else clause
+ refs: selectively set prefix in the seek functions
+ ref-cache: remove unused function 'find_ref_entry()'
+ refs: expose ref_iterator via 'refs.h' (this branch is used by kn/for-each-ref-skip-updates.)
"git for-each-ref" learns "--start-after" option to help applications that want to page its output.
source: <20250715-306-git-for-each-ref-pagination-v5-0-852d5a2f56e1@gmail.com>
* ly/pull-autostash (2025-07-20) 1 commit
(merged to 'next' on 2025-07-24 at dd85f09d69)
+ pull: add pull.autoStash config option
"git pull" learned to pay attention to pull.autostash configuration variable, which overrides rebase/merge.autostash.
source: <[email protected]>
* ow/rebase-verify-insn-fmt-before-initializing-state (2025-06-09) 1 commit (merged to 'next' on 2025-07-28 at 561f172338)
+ rebase: write script before initializing state
"git rebase -i" with bogus rebase.instructionFormat configuration failed to produce the todo file after recording the state files, leading to confused "git status"; this has been corrected.
source: <[email protected]>
* ps/object-store-midx (2025-07-15) 9 commits
(merged to 'next' on 2025-07-28 at a6727995ac)
+ midx: remove now-unused linked list of multi-pack indices
+ packfile: stop using linked MIDX list in get_all_packs()
+ packfile: stop using linked MIDX list in find_pack_entry()
+ packfile: refactor get_multi_pack_index() to work on sources
+ midx: stop using linked list when closing MIDX
+ packfile: refactor prepare_packed_git_one() to work on sources
+ midx: start tracking per object database source
+ Merge branch 'tb/midx-avoid-cruft-packs' into ps/object-store-midx
+ Merge branch 'ps/object-store' into ps/object-store-midx (this branch is used by ps/object-store-midx-dedup-info.)
Redefine where the multi-pack-index sits in the object subsystem, which recently was restructured to allow multiple backends that support a single object source that belongs to one repository. A midx does span mulitple "object sources".
cf. <[email protected]>
source: <[email protected]>
* sk/reftable-clarify-tests (2025-07-24) 10 commits
(merged to 'next' on 2025-07-24 at b3930223b7)
+ t/unit-tests: finalize migration of reftable-related tests
+ t/unit-tests: convert reftable stack test to use clar
+ t/unit-tests: convert reftable record test to use clar
+ t/unit-tests: convert reftable readwrite test to use clar
+ t/unit-tests: convert reftable table test to use clar
+ t/unit-tests: convert reftable pq test to use clar
+ t/unit-tests: convert reftable merged test to use clar
+ t/unit-tests: convert reftable block test to use clar
+ t/unit-tests: convert reftable basics test to use clar test framework
+ t/unit-tests: implement clar specific reftable test helper functions
The reftable unit tests are now ported to the "clar" unit testing framework.
cf. <[email protected]>
source: <[email protected]>
--------------------------------------------------
[New Topics]
* jc/doc-release-vs-clear (2025-08-01) 1 commit
(merged to 'next' on 2025-08-01 at dd9490d97e)
+ CodingGuidelines: clarify that S_release() does not reinitialize
Doc update.
Will merge to 'master'.
source: <[email protected]>
* kh/doc-fast-import-historical (2025-08-01) 1 commit (merged to 'next' on 2025-08-01 at 111a582ca4)
+ doc: fast-import: contextualize the hardware cost
Doc update.
Will merge to 'master'.
source: <a9bc7547a27aab8bc2404caeb821b7f5c4c10d14.1754055658.git.code@khaugsbakk.name>
* ms/meson-with-ancient-git-wo-ls-files-dedup (2025-08-01) 1 commit (merged to 'next' on 2025-08-01 at f2b8c802ec)
+ meson: tolerate errors from git ls-files --deduplicate
Build fix.
Will merge to 'master'.
source: <[email protected]>
* pw/reftable-libgit2-cleanup (2025-08-01) 5 commits
- reftable/stack: allow passing flags to reftable_stack_add()
- reftable/stack: reorder code to avoid forward declarations
- reftable/stack: fix compiler warning due to missing braces
- reftable/writer: drop Git-specific QSORT() macro
- reftable/writer: fix type used for number of records
Code clean-ups.
Comments?
source: <[email protected]>
* tc/diff-tree-max-depth (2025-07-29) 3 commits
- diff: teach tree-diff a max-depth parameter
- within_depth: fix return for empty path
- combine-diff: zero memory used for callback filepairs
"git diff-tree" learned "--max-depth" option.
Comments?
source: <[email protected]>
* dk/help-all (2025-08-03) 4 commits
- builtin: also setup gently for --help-all
- parse-options: refactor flags for usage_with_options_internal
- t1517: fixup for ua/t1517-short-help-tests
- Merge branch 'ua/t1517-short-help-tests' into dk/help-all (this branch uses ua/t1517-short-help-tests.)
"git cmd --help-all" outside repository.
Breaks t1517.296 under SANITIZE=leak?
source: <[email protected]>
* js/mingw-fixes (2025-08-03) 4 commits
(merged to 'next' on 2025-08-03 at a222fda8c6)
+ mingw: support Windows Server 2016 again
+ mingw_rename: support ReFS on Windows 2022
+ mingw: drop Windows 7-specific work-around
+ mingw_open_existing: handle directories better
Windows fixes.
Will merge to 'master'.
source: <[email protected]>
* jt/archive-zip-deflate-fix (2025-08-02) 1 commit
- archive: flush deflate stream until Z_STREAM_END
The deflate codepath in "git archive --format=zip" had a longstanding bug coming from misuse of zlib API, which has been corrected.
Will merge to 'next'.
source: <[email protected]>
* lc/rebase-trailer (2025-08-03) 2 commits
- rebase: support --trailer
- trailer: append trailers in-process and drop the fork to interpret-trailers
source: <[email protected]>
* ly/diff-name-only-with-diff-from-content (2025-08-03) 1 commit . diff: ensure consistent diff behavior with -I<regex> across output formats
Various options to "git diff" that makes comparison ignore certain aspects of the differences (like "space changes are ignored", "differences in lines that match these regular expressions are ignored") did not work well with "--name-only" and friends.
Breaks t3040 when merged to 'seen'.
source: <[email protected]>
* rs/describe-with-prio-queue (2025-08-03) 2 commits
- describe: use prio_queue_replace()
- describe: use prio_queue
"git describe" has been optimized by using better data structure.
Will merge to 'next'?
source: <[email protected]>
--------------------------------------------------
[Cooking]
* ps/meson-clar-decls-fix (2025-07-29) 1 commit (merged to 'next' on 2025-08-01 at 627c189731)
+ meson: ensure correct "clar-decls.h" header is used
Build fix.
Will merge to 'master'.
source: <20250729-b4-pks-meson-unit-tests-stale-decls-v1-1-4a7770c84307@pks.im>
* ps/object-store-midx-dedup-info (2025-07-29) 9 commits
- midx: compute paths via their source
- midx: stop duplicating info redundant with its owning source
- midx: write multi-pack indices via their source
- midx: load multi-pack indices via their source
- midx: drop redundant struct repository parameter
- odb: return newly created in-memory sources
- odb: allow odb_find_source() to fail
- odb: store locality in object database sources
- Merge branch 'ps/object-store-midx' into ps/object-store-midx-dedup-info
Further code clean-up for multi-pack-index code paths.
Comments?
source: <20250729-b4-pks-midx-deduplicate-source-info-v1-0-748db2eda3b5@pks.im>
* ch/t7450-recursive-clone-test-fix (2025-07-30) 1 commit (merged to 'next' on 2025-08-01 at 478a84a4a9)
+ t7450: inspect the correct path a broken code would write to
Test fix.
Will merge to 'master'.
source: <[email protected]>
* jc/strbuf-split (2025-07-31) 13 commits
- trace2: do not use strbuf_split*()
- trace2: trim_trailing_newline followed by trim is a no-op
- sub-process: do not use strbuf_split*()
- environment: do not use strbuf_split*()
- config: do not use strbuf_split()
- notes: do not use strbuf_split*()
- merge-tree: do not use strbuf_split*()
- clean: do not use strbuf_split*() [part 2]
- clean: do not pass the whole structure when it is not necessary
- clean: do not use strbuf_split*() [part 1]
- clean: do not pass strbuf by value
- wt-status: avoid strbuf_split*()
- Merge branch 'jc/string-list-split' into jc/strbuf-split (this branch uses jc/string-list-split.)
Arrays of strbuf is often a wrong data structure to use, and strbuf_split*() family of functions that create them often have better alternatives.
Update several code paths and replace strbuf_split*().
Will merge to 'next'?
source: <[email protected]>
* jc/string-list-split (2025-08-01) 7 commits
- string-list: split-then-remove-empty can be done while splitting
- string-list: optionally omit empty string pieces in string_list_split*()
- diff: simplify parsing of diff.colormovedws
- string-list: optionally trim string pieces split by string_list_split*()
- string-list: unify string_list_split* functions
- string-list: align string_list_split() with its _in_place() counterpart
- string-list: report programming error with BUG
(this branch is used by jc/strbuf-split.)
string_list_split*() family of functions have been extended to simplify common use cases.
Will merge to 'next'?
source: <[email protected]>
* jc/test-hashmap-is-still-here (2025-07-30) 1 commit (merged to 'next' on 2025-08-01 at 0d766613fc)
+ test-hashmap: document why it is no longer used but still there
Comment fix.
Will merge to 'master'.
source: <[email protected]>
* js/prompt-crlf-fix (2025-07-31) 1 commit
(merged to 'next' on 2025-08-01 at 365b52c100)
+ interactive: do strip trailing CRLF from input
Interactive prompt code did not correctly strip CRLF from the end of line on Windows.
Will merge to 'master'.
source: <[email protected]>
* am/xdiff-hash-tweak (2025-07-28) 3 commits
- fixup! xdiff: optimize xdl_hash_record_verbatim
- xdiff: optimize xdl_hash_record_verbatim
- xdiff: refactor xdl_hash_record()
Inspired by Ezekiel's recent effort to showcase Rust interface, the hash function implementation used to hash lines have been updated to the one used for ELF symbol lookup by Glibc.
Comments?
source: <[email protected]>
* cc/t9350-cleanup (2025-07-25) 1 commit
(merged to 'next' on 2025-07-29 at 3d39401b01)
+ t9350: redirect input to only fast-import
Test clean-up.
Will merge to 'master'.
source: <[email protected]>
* hy/blame-simplify-get-commit-info (2025-07-27) 1 commit (merged to 'next' on 2025-07-29 at aa7b9a8ab6)
+ blame: remove parameter detailed in get_commit_info()
Code simplification.
Will merge to 'master'.
source: <[email protected]>
* kn/for-each-ref-skip-updates (2025-07-28) 5 commits (merged to 'next' on 2025-07-29 at 6e97c528ef)
+ ref-filter: use REF_ITERATOR_SEEK_SET_PREFIX instead of '1'
+ t6302: add test combining '--start-after' with '--exclude'
+ for-each-ref: reword the documentation for '--start-after'
+ for-each-ref: fix documentation argument ordering
+ ref-cache: use 'size_t' instead of int for length
Code clean-up.
Will merge to 'master'.
cf. <[email protected]>
source: <[email protected]>
* ps/remote-rename-fix (2025-07-31) 7 commits
- builtin/remote: only iterate through refs that are to be renamed
- builtin/remote: rework how remote refs get renamed
- builtin/remote: determine whether refs need renaming early on
- builtin/remote: fix sign comparison warnings
- refs: simplify logic when migrating reflog entries
- refs: pass refname when invoking reflog entry callback
- Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix (this branch uses ps/reflog-migrate-fixes.)
"git remote rename origin upstream" failed to move origin/HEAD to upstream/HEAD when origin/HEAD is unborn and performed other renames extremely inefficiently, which has been corrected.
Will merge to 'next'?
source: <[email protected]>
* rs/tighten-alias-help (2025-07-25) 1 commit
(merged to 'next' on 2025-08-01 at a0fb0696cd)
+ git: show alias info only with lone -h
"git -c alias.foo=bar foo -h baz" reported "'foo' is aliased to 'bar'" and then went on to do "git foo -h baz", which was unexpected. Tighten the rule so that alias expansion is reported only when "-h" is the sole option.
Will merge to 'master'.
source: <[email protected]>
* ag/send-email-imap-sent (2025-07-22) 1 commit
- send-email: add ability to send a copy of sent emails to an IMAP folder
"git send-email" learned to drive "git imap-send" to store already sent e-mails in an IMAP folder.
A reroll (v4) exists.
cf. <PN3PR01MB9597EC4C5DF97943587AEEB4B85FA@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
source: <da7cee769f25871ed3f934e3ec7f2cccf0a0420c.1753182534.git.gargaditya08@live.com>
* en/ort-rename-fixes (2025-07-22) 6 commits
- merge-ort: fix directory rename on top of source of other rename/delete
- merge-ort: fix incorrect file handling
- t6423: fix missed staging of file in testcases 12i,12j,12k
- t6423: document two bugs with rename-to-self testcases
- merge-ort: drop unnecessary temporary in check_for_directory_rename()
- merge-ort: update comments to modern testfile location
Various bugs about rename handling in "ort" merge strategy have been fixed.
Expecting a reroll?
cf. <[email protected]>
source: <[email protected]>
* jb/t7510-gpg-program-path (2025-07-24) 2 commits (merged to 'next' on 2025-07-29 at f5dc13f52d)
+ t7510: use $PWD instead of $(pwd) inside PATH (merged to 'next' on 2025-07-24 at eb8bc447f9)
+ t7510: add test cases for non-absolute gpg program
A new test to ensure that a recent change will keep working.
Will merge to 'master'.
cf. <[email protected]>
source: <[email protected]>
source: <[email protected]>
* jt/switch-restore-no-longer-experimental (2025-07-28) 1 commit (merged to 'next' on 2025-07-29 at 3c2cf5ab46)
+ builtin: unmark git-switch and git-restore as experimental
Declare that "git switch" and "git restore" are no longer experimental.
Will merge to 'master'.
source: <[email protected]>
* ps/reflog-migrate-fixes (2025-07-29) 9 commits
- refs: fix invalid old object IDs when migrating reflogs
- refs: stop unsetting REF_HAVE_OLD for log-only updates
- refs/files: detect race when generating reflog entry for HEAD
- refs: fix identity for migrated reflogs
- ident: fix type of string length parameter
- builtin/reflog: implement subcommand to write new entries
- refs: export ref_transaction_update_reflog()
- builtin/reflog: improve grouping of subcommands
- Documentation/git-reflog: convert to use synopsis type (this branch is used by ps/remote-rename-fix.)
"git refs migrate" to migrate the reflog entries from a refs backend to another had a handful of bugs squashed.
Will merge to 'next'?
source: <[email protected]>
* ds/sparse-checkout-clean (2025-07-16) 9 commits
- sparse-checkout: make 'clean' clear more files
- t: expand tests around sparse merges and clean
- sparse-index: point users to new 'clean' action
- sparse-checkout: add --verbose option to 'clean'
- dir: add generic "walk all files" helper
- sparse-checkout: match some 'clean' behavior
- sparse-checkout: add basics of 'clean' command
- sparse-checkout: remove use of the_repository
- Merge branch 'ac/deglobal-sparse-variables' into ds/sparse-checkout-clean (this branch uses ac/deglobal-sparse-variables.)
"git sparse-checkout" subcommand learned a new "clean" action to prune otherwise unused working-tree files that are outside the areas of interest.
Needs to wait for the base topic to solidify.
source: <[email protected]>
* ps/config-wo-the-repository (2025-07-23) 22 commits
(merged to 'next' on 2025-07-29 at 13da88e8fb)
+ config: fix sign comparison warnings
+ config: move Git config parsing into "environment.c"
+ config: remove unused the_repository wrappers
+ config: drop git_config_set_multivar() wrapper
+ config: drop git_config_get_multivar_gently() wrapper
+ config: drop git_config_set_multivar_in_file_gently() wrapper
+ config: drop git_config_set_in_file_gently() wrapper
+ config: drop git_config_set() wrapper
+ config: drop git_config_set_gently() wrapper
+ config: drop git_config_set_in_file() wrapper
+ config: drop git_config_get_bool() wrapper
+ config: drop git_config_get_ulong() wrapper
+ config: drop git_config_get_int() wrapper
+ config: drop git_config_get_string() wrapper
+ config: drop git_config_get_string() wrapper
+ config: drop git_config_get_string_multi() wrapper
+ config: drop git_config_get_value() wrapper
+ config: drop git_config_get_value() wrapper
+ config: drop git_config_get() wrapper
+ config: drop git_config_clear() wrapper
+ config: drop git_config() wrapper
+ Merge branch 'bc/use-sha256-by-default-in-3.0' into ps/config-wo-the-repository (this branch is used by pw/3.0-commentchar-auto-deprecation.)
The config API had a set of convenience wrapper functions that implicitly use the_repository instance; they have been removed and inlined at the calling sites.
Will merge to 'master'.
source: <[email protected]>
* pw/3.0-commentchar-auto-deprecation (2025-07-31) 4 commits
- commit: print advice when core.commentString=auto
- config: warn on core.commentString=auto
- breaking-changes: deprecate support for core.commentString=auto
- Merge branch 'ps/config-wo-the-repository' into pw/3.0-commentchar-auto-deprecation (this branch uses ps/config-wo-the-repository.)
Proposes to deprecate "core.commentChar=auto" that attempts to dynamically pick a suitable comment character, as it is too much trouble to support for little benefit.
Comments?
source: <[email protected]>
* ps/object-file-wo-the-repository (2025-07-16) 17 commits (merged to 'next' on 2025-08-01 at 0c1253014e)
+ object-file: get rid of the_repository in index-related functions
+ object-file: get rid of the_repository in force_object_loose()
+ object-file: get rid of the_repository in read_loose_object()
+ object-file: get rid of the_repository in loose object iterators
+ object-file: remove declaration for for_each_file_in_obj_subdir()
+ object-file: inline for_each_loose_file_in_objdir_buf()
+ object-file: get rid of the_repository when writing objects
+ odb: introduce odb_write_object()
+ loose: write loose objects map via their source
+ object-file: get rid of the_repository in finalize_object_file()
+ object-file: get rid of the_repository in loose_object_info()
+ object-file: get rid of the_repository when freshening objects
+ object-file: inline check_and_freshen() functions
+ object-file: get rid of the_repository in has_loose_object()
+ object-file: stop using the_hash_algo
+ object-file: fix -Wsign-compare warnings
+ Merge branch 'ps/object-store' into ps/object-file-wo-the-repository
Reduce implicit assumption and dependence on the_repository in the object-file subsystem.
Will merge to 'master'.
cf. <[email protected]>
cf. <[email protected]>
source: <20250717-pks-object-file-wo-the-repository-v2-0-36d2cd6c700e@pks.im>
* ua/t1517-short-help-tests (2025-08-02) 3 commits
- t5304: move prune -h test from t1517
- t5200: move update-server-info -h test from t1517
- t/t1517: automate git subcmd -h tests outside a repository (this branch is used by dk/help-all.)
Test shuffling.
Needs the perl-prereq touch-up squashed in from dk/help-all topic.
source: <[email protected]>
* tc/last-modified (2025-07-30) 4 commits
- last-modified: use Bloom filters when available
- commit-graph: export prepare_commit_graph()
- t/perf: add last-modified perf script
- last-modified: new subcommand to show when files were last modified
A new command "git last-modified" is proposed to show the closest ancestor commit that touched each path.
Seems to break a CI job when merged to 'seen'. cf. <[email protected]>
source: <[email protected]>
* lo/repo-info (2025-08-01) 5 commits
. repo: add the --format flag
. repo: add the field layout.shallow
. repo: add the field layout.bare
. repo: add the field references.format
. repo: declare the repo command
A new subcommand "git repo" gives users a way to grab various repository characteristics.
Breaks 0450 when merged to 'seen'.
source: <[email protected]>
* ac/deglobal-sparse-variables (2025-07-18) 3 commits
- environment: remove the global variable 'sparse_expect_files_outside_of_patterns'
- environment: move access to "core.sparsecheckoutcone" into repo_settings
- environment: move access to "core.sparsecheckout" into repo_settings (this branch is used by ds/sparse-checkout-clean.)
Two global variables related to sparse checkout have been moved to the repository settings structure.
Expecting a reroll.
cf. <CAE7as+bnG6KgA8X_n36pqP15bmyM6re+xEb1MOXKvZSUdJ8Arg@mail.gmail.com>
source: <[email protected]>
* tb/prepare-midx-pack-cleanup (2025-05-28) 5 commits
- midx: return a packed_git pointer from prepare_midx_pack()
- midx-write.c: extract inner loop from fill_packs_from_midx()
- midx-write.c: guard against incremental MIDXs in want_included_pack()
- midx: access pack names through nth_midxed_pack_name()
- Merge branch 'ps/midx-negative-packfile-cache' into tb/prepare-midx-pack-cleanup
Improvement on Multi-pack-index API.
Expecting a reroll.
cf. <[email protected]>
source: <[email protected]>
* kj/renamed-submodule (2025-07-24) 4 commits
(merged to 'next' on 2025-08-03 at c341b36545)
+ fixup! submodule: skip redundant active entries when pattern covers path
+ fixup! submodule: prevent overwriting .gitmodules on path reuse
+ submodule: skip redundant active entries when pattern covers path
+ submodule: prevent overwriting .gitmodules on path reuse
The case where a new submodule takes a path where used to be a completely different subproject is now dealt a bit better than before.
Will merge to 'master'.
source: <[email protected]>
* lm/add-p-context (2025-07-29) 4 commits (merged to 'next' on 2025-07-29 at 393fa4b64b)
+ add-patch: add diff.context command line overrides
+ add-patch: respect diff.context configuration
+ t: use test_config in t4055
+ t: use test_grep in t3701 and t4055
"git add/etc -p" now honors diff.context configuration variable, and learns to honor -U<n> option.
Will merge to 'master'.
source: <[email protected]>
* cc/promisor-remote-capability (2025-07-31) 5 commits
- promisor-remote: use string constants for 'name' and 'url' too
- promisor-remote: allow a client to check fields
- promisor-remote: refactor how we parse advertised fields
- promisor-remote: allow a server to advertise more fields
- promisor-remote: refactor to get rid of 'struct strvec'
The "promisor-remote" capability mechanism has been updated to allow the "partialCloneFilter" settings and the "token" value to be communicated from the server side.
Expecting a reroll.
source: <[email protected]>
--------------------------------------------------
[Discarded]
* pw/compound-literal-test-balloon (2025-07-14) 1 commit . strbuf: add compound literal test balloon
Gauge if the world is ready for compound literal that can make the resulting code clearer in some places.
Discarded; it turns out that we already have a test balloon on this.
source: <7ac55a5096c261b706f47ca239c381f71db2b67a.1752499653.git.phillip.wood@dunelm.org.uk>
* jc/tag-idempotent-no-op (2025-07-11) 1 commit . tag: allow idempotent "git tag" without "--force"
"git tag T O" when the tag T is already pointing at the object O is a no-op; we used to but no longer error out such a request and require "--force" and instead turn it into a no-op.
Will discard.
cf. <dt5ruadvr7lmhsbypmb6yili5cookfx5btw4gzfeui7ehxxajv@ziael4udbbcy>
source: <[email protected]>
Quoted 10 lines · Junio C Hamano
* ps/remote-rename-fix (2025-07-31) 7 commits
- builtin/remote: only iterate through refs that are to be renamed
- builtin/remote: rework how remote refs get renamed
- builtin/remote: determine whether refs need renaming early on
- builtin/remote: fix sign comparison warnings
- refs: simplify logic when migrating reflog entries
- refs: pass refname when invoking reflog entry callback
- Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix (this branch uses ps/reflog-migrate-fixes.)
Quoted 6 lines
"git remote rename origin upstream" failed to move origin/HEAD to upstream/HEAD when origin/HEAD is unborn and performed other renames extremely inefficiently, which has been corrected.
Will merge to 'next'?
source: <[email protected]>
I've sent one more version of this patch series for a couple of final finishing touches. If Peff is happy with that version I'm happy to see it merged.
Quoted 12 lines
* ps/reflog-migrate-fixes (2025-07-29) 9 commits
- refs: fix invalid old object IDs when migrating reflogs
- refs: stop unsettingREF_HAVE_OLDfor log-only updates
- refs/files: detect race when generating reflog entry for HEAD
- refs: fix identity for migrated reflogs
- ident: fix type of string length parameter
- builtin/reflog: implement subcommand to write new entries
- refs: exportref_transaction_update_reflog()
- builtin/reflog: improve grouping of subcommands
-Documentation/git-reflog: convert to use synopsis type (this branch is used by ps/remote-rename-fix.)
Quoted 5 lines
"git refs migrate" to migrate the reflog entries from a refs backend to another had a handful of bugs squashed.
Will merge to 'next'?
source: <[email protected]>
I'm happy with this version, so if the above goes in I think this one here can also be merged.
Thanks!
Patrick
Quoted 15 lines · Patrick Steinhardt
Quoted 14 lines · Junio C Hamano
* ps/remote-rename-fix (2025-07-31) 7 commits
- builtin/remote: only iterate through refs that are to be renamed
- builtin/remote: rework how remote refs get renamed
- builtin/remote: determine whether refs need renaming early on
- builtin/remote: fix sign comparison warnings
- refs: simplify logic when migrating reflog entries
- refs: pass refname when invoking reflog entry callback
- Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix (this branch uses ps/reflog-migrate-fixes.)"git remote rename origin upstream" failed to move origin/HEAD to upstream/HEAD when origin/HEAD is unborn and performed other renames extremely inefficiently, which has been corrected.
Quoted 6 lines
Quoted 2 lines
Will merge to 'next'?
source: <[email protected]>I've sent one more version of this patch series for a couple of final finishing touches. If Peff is happy with that version I'm happy to see it merged.
Hmph, you have?
Quoted 13 lines
Quoted 13 lines
* ps/reflog-migrate-fixes (2025-07-29) 9 commits
- refs: fix invalid old object IDs when migrating reflogs
- refs: stop unsettingREF_HAVE_OLDfor log-only updates
- refs/files: detect race when generating reflog entry for HEAD
- refs: fix identity for migrated reflogs
- ident: fix type of string length parameter
- builtin/reflog: implement subcommand to write new entries
- refs: exportref_transaction_update_reflog()
- builtin/reflog: improve grouping of subcommands
-Documentation/git-reflog: convert to use synopsis type (this branch is used by ps/remote-rename-fix.)
Quoted 8 lines
Quoted 5 lines
"git refs migrate" to migrate the reflog entries from a refs backend to another had a handful of bugs squashed.
Will merge to 'next'?
source: <[email protected]>I'm happy with this version, so if the above goes in I think this one here can also be merged.
You have an update for this one. Perhaps your comments are swapped between these two topics?
Quoted 42 lines · Junio C Hamano
Quoted 15 lines · Patrick Steinhardt
Quoted 14 lines · Junio C Hamano
* ps/remote-rename-fix (2025-07-31) 7 commits
- builtin/remote: only iterate through refs that are to be renamed
- builtin/remote: rework how remote refs get renamed
- builtin/remote: determine whether refs need renaming early on
- builtin/remote: fix sign comparison warnings
- refs: simplify logic when migrating reflog entries
- refs: pass refname when invoking reflog entry callback
- Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix (this branch uses ps/reflog-migrate-fixes.)"git remote rename origin upstream" failed to move origin/HEAD to upstream/HEAD when origin/HEAD is unborn and performed other renames extremely inefficiently, which has been corrected.
Quoted 6 lines
Quoted 2 lines
Will merge to 'next'?
source: <[email protected]>I've sent one more version of this patch series for a couple of final finishing touches. If Peff is happy with that version I'm happy to see it merged.
Hmph, you have?
Quoted 16 lines
Quoted 16 lines
* ps/reflog-migrate-fixes (2025-07-29) 9 commits
- refs: fix invalid old object IDs when migrating reflogs
- refs: stop unsettingREF_HAVE_OLDfor log-only updates
- refs/files: detect race when generating reflog entry for HEAD
- refs: fix identity for migrated reflogs
- ident: fix type of string length parameter
- builtin/reflog: implement subcommand to write new entries
- refs: exportref_transaction_update_reflog()
- builtin/reflog: improve grouping of subcommands
-Documentation/git-reflog: convert to use synopsis type (this branch is used by ps/remote-rename-fix.)"git refs migrate" to migrate the reflog entries from a refs backend to another had a handful of bugs squashed.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Will merge to 'next'?
source: <[email protected]>I'm happy with this version, so if the above goes in I think this one here can also be merged.
You have an update for this one. Perhaps your comments are swapped between these two topics?
Oh, indeed. Sorry for the confusion.
Patrick
Quoted 18 lines · Patrick Steinhardt
Quoted 18 lines
Quoted 18 lines
Quoted 17 lines
* ps/reflog-migrate-fixes (2025-07-29) 9 commits
- refs: fix invalid old object IDs when migrating reflogs
- refs: stop unsettingREF_HAVE_OLDfor log-only updates
- refs/files: detect race when generating reflog entry for HEAD
- refs: fix identity for migrated reflogs
- ident: fix type of string length parameter
- builtin/reflog: implement subcommand to write new entries
- refs: exportref_transaction_update_reflog()
- builtin/reflog: improve grouping of subcommands
-Documentation/git-reflog: convert to use synopsis type (this branch is used by ps/remote-rename-fix.)"git refs migrate" to migrate the reflog entries from a refs backend to another had a handful of bugs squashed.
Will merge to 'next'?
source: <[email protected]>
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I'm happy with this version, so if the above goes in I think this one here can also be merged.
You have an update for this one. Perhaps your comments are swapped between these two topics?
Oh, indeed. Sorry for the confusion.
I just left a rather lengthy review of the split-HEAD patch in v4. I think hit has a few bugs that we need to address.
I'm not sure if the right answer is to just go back to the v3 version that simply rejected the racy HEAD update (since that's more or less what happens now and nobody complains).
If we do want to stick with the "silently skip the racy HEAD update" strategy from v4, I left some fixes there. But I'd worry more about maintainability and regressions in the future. I'm not sure if my hacky "pretend the HEAD is this for splitting" patch is something we'd want to carry or not. But if so, I think we could at least get a little coverage in the test suite.
-Peff
Quoted 7 lines · Jeff King
I just left a rather lengthy review of the split-HEAD patch in v4. I think hit has a few bugs that we need to address.
I'm not sure if the right answer is to just go back to the v3 version that simply rejected the racy HEAD update (since that's more or less what happens now and nobody complains).
Quoted 6 lines
If we do want to stick with the "silently skip the racy HEAD update" strategy from v4, I left some fixes there. But I'd worry more about maintainability and regressions in the future. I'm not sure if my hacky "pretend the HEAD is this for splitting" patch is something we'd want to carry or not. But if so, I think we could at least get a little coverage in the test suite.
Between the "honestry admit we failed and reject" and "silently pretend nothing bad happened", I'd have to say that the former may be more preferrable, and I hope people would agree.
Quoted 11 lines · Junio C Hamano
* dk/help-all (2025-08-03) 4 commits
- builtin: also setup gently for --help-all
- parse-options: refactor flags forusage_with_options_internal
- t1517: fixup for ua/t1517-short-help-tests
- Merge branch 'ua/t1517-short-help-tests' into dk/help-all (this branch uses ua/t1517-short-help-tests.)"git cmd --help-all" outside repository.
Breaks t1517.296 under SANITIZE=leak?
source: <[email protected]>
I don't see the link in the linux-leaks job of a recent CI run [1]. When I build with
make SANITIZE=leak CC=gcc-14
(since clang on my system doesn't support -fsantize=leak for x86_64-apple-darwin21.6.0) and then
(cd t && prove t1517*)
then I get
t1517-outside-repo.sh .. ok
All tests successful.
Files=1, Tests=392, 22 wallclock secs ( 0.10 usr 0.01 sys + 5.26cusr 4.40 csys = 9.77 CPU)
Result: PASS
So I don't think this topic is the problem. This is true whether I use my copy of the topic or the one you publish (4c8db1e55c (builtin: also setup gently for --help-all, 2025-08-03)).
[1]: https://github.com/benknoble/git/actions/runs/16706744996/job/47285921358
Quoted 3 lines · D. Ben Knoble
.... This is true whether I use
my copy of the topic or the one you publish (4c8db1e55c(builtin: also setup gently for --help-all, 2025-08-03)).
I think the breakage I saw was while testing the 'seen' branch as a whole, so there may be some interactions with other topics. IIRC, it was running "git repo --help-all" when I saw the complaints.
Quoted 16 lines · Junio C Hamano
Quoted 7 lines · Jeff King
I just left a rather lengthy review of the split-HEAD patch in v4. I think hit has a few bugs that we need to address.
I'm not sure if the right answer is to just go back to the v3 version that simply rejected the racy HEAD update (since that's more or less what happens now and nobody complains).
Quoted 6 lines
If we do want to stick with the "silently skip the racy HEAD update" strategy from v4, I left some fixes there. But I'd worry more about maintainability and regressions in the future. I'm not sure if my hacky "pretend the HEAD is this for splitting" patch is something we'd want to carry or not. But if so, I think we could at least get a little coverage in the test suite.
Quoted 3 lines
Between the "honestry admit we failed and reject" and "silently pretend nothing bad happened", I'd have to say that the former may be more preferrable, and I hope people would agree.
I think I don't think it's pretending that nothing bad happened, though. The user did not ask us to update HEAD, and we are able to fill their original request completely. So there really was nothing bad that happened.
To me the options are "try to do the best thing in a racy situation, even though it almost never happens and will be complex and somewhat untested" vs "do the simple and stupid thing that does not happen enough for anyone to care too much".
-Peff
Quoted 16 lines · Junio C Hamano
Quoted 7 lines · Jeff King
I just left a rather lengthy review of the split-HEAD patch in v4. I think hit has a few bugs that we need to address.
I'm not sure if the right answer is to just go back to the v3 version that simply rejected the racy HEAD update (since that's more or less what happens now and nobody complains).
Quoted 6 lines
If we do want to stick with the "silently skip the racy HEAD update" strategy from v4, I left some fixes there. But I'd worry more about maintainability and regressions in the future. I'm not sure if my hacky "pretend the HEAD is this for splitting" patch is something we'd want to carry or not. But if so, I think we could at least get a little coverage in the test suite.
Quoted 3 lines
Between the "honestry admit we failed and reject" and "silently pretend nothing bad happened", I'd have to say that the former may be more preferrable, and I hope people would agree.
I am a bit torn overall. We _are_ talking about a race, even though it is an implicit race because the user didn't explicitly ask for the ref to be updated. So aborting the transaction is reasonable from my perspective. But as Peff noted the user didn't ask for it explicitly, so it may be surprising if we abort due to a concurrent update of HEAD.
Ultimately I'd claim that no end user will ever see this happen in practice. You'd have to change HEAD at the same point in time as you write a new commit directly to the branch that it's pointing to. That is, git-commit(1) wouldn't even be able to trigger this case as that command commits to HEAD, not to its target. And just to confirm my
claim: setting a breakpoint in split_head_update() and then executing "git commit" doesn't trigger that function.
So with that knowledge I'd rather do the safe thing and abort the transaction. It requires less hard-to-test logic and feels safer overall.
If we agree on that I can send a final reroll that reverts back to the logic we had in v3, which did abort the transaction.
Patrick
Quoted 6 lines · Patrick Steinhardt
I am a bit torn overall. We _are_ talking about a race, even though it is an implicit race because the user didn't explicitly ask for the ref to be updated. So aborting the transaction is reasonable from my perspective. But as Peff noted the user didn't ask for it explicitly, so it may be surprising if we abort due to a concurrent update of HEAD.
Quoted 7 lines
Ultimately I'd claim that no end user will ever see this happen in practice. You'd have to change HEAD at the same point in time as you write a new commit directly to the branch that it's pointing to. That is, git-commit(1) wouldn't even be able to trigger this case as that command commits to HEAD, not to its target. And just to confirm my
claim: setting a breakpoint insplit_head_update()and then executing "git commit" doesn't trigger that function.
Yes, I think it's pretty unlikely on the client, where almost all of your ref updates are either via HEAD (because you're committing), or to remote tracking branches via fetch (and we never point HEAD there).
The more likely case is a server where one user is pushing and another updates HEAD (to set the default branch for clones, etc). But those sorts of updates to HEAD are going to be rather rare there, as well.
So I agree it's not that likely to come up much in practice.
Quoted 3 lines
So with that knowledge I'd rather do the safe thing and abort the transaction. It requires less hard-to-test logic and feels safer overall.
I'm OK with that.
Quoted 2 lines
If we agree on that I can send a final reroll that reverts back to the logic we had in v3, which did abort the transaction.
Yep, sounds good.
-Peff
Quoted 10 lines · Junio C Hamano
Quoted 3 lines · D. Ben Knoble
.... This is true whether I use
my copy of the topic or the one you publish (4c8db1e55c(builtin: also setup gently for --help-all, 2025-08-03)).I think the breakage I saw was while testing the 'seen' branch as a whole, so there may be some interactions with other topics. IIRC, it was running "git repo --help-all" when I saw the complaints.
Hm. Will try again with the whole seen branch, but after merging lo/repo-info locally then
make -j $(nproc) SANITIZE=leak CC=gcc-14
(cd t && prove t1517*)still didn't fail.
Signature · 1 line
D. Ben Knoble
Quoted 13 lines · D. Ben Knoble
Quoted 10 lines · Junio C Hamano
Quoted 3 lines · D. Ben Knoble
.... This is true whether I use
my copy of the topic or the one you publish (4c8db1e55c(builtin: also setup gently for --help-all, 2025-08-03)).I think the breakage I saw was while testing the 'seen' branch as a whole, so there may be some interactions with other topics. IIRC, it was running "git repo --help-all" when I saw the complaints.
Quoted 7 lines
Hm. Will try again with the whole seen branch, but after merging lo/repo-info locally then
make -j $(nproc) SANITIZE=leak CC=gcc-14 (cd t && prove t1517*)still didn't fail.
With apologies for the mail noise, but I can't seem to reproduce any failures here on 371c45b569 (Merge branch 'dk/help-all' into seen, 2025-08-04), which is the latest seen I can find.
Quoted 9 lines · Jeff King
I think I don't think it's pretending that nothing bad happened, though. The user did not ask us to update HEAD, and we are able to fill their original request completely. So there really was nothing bad that happened.
To me the options are "try to do the best thing in a racy situation, even though it almost never happens and will be complex and somewhat untested" vs "do the simple and stupid thing that does not happen enough for anyone to care too much".
OK. I still prefer the latter ;-)
Thanks.
Quoted 6 lines · Patrick Steinhardt
So with that knowledge I'd rather do the safe thing and abort the transaction. It requires less hard-to-test logic and feels safer overall.
If we agree on that I can send a final reroll that reverts back to the logic we had in v3, which did abort the transaction.
I guess both you and Peff also prefer code that is more maintainable and easier to reason about, and I am with you two, so let's go back to the approach of v3.
Thanks.
Quoted 7 lines · Junio C Hamano
Quoted 5 lines · Jeff King
I think I don't think it's pretending that nothing bad happened, though. The user did not ask us to update HEAD, and we are able to fill their original request completely. So there really was nothing bad that happened.
Quoted 6 lines
Quoted 4 lines
To me the options are "try to do the best thing in a racy situation, even though it almost never happens and will be complex and somewhat untested" vs "do the simple and stupid thing that does not happen enough for anyone to care too much".
OK. I still prefer the latter ;-)
Yeah, sorry if I was not clear. I was just quibbling about the framing of the discussion, but I think we all ended up in the same place. ;)
-Peff
Quoted 3 lines · D. Ben Knoble
With apologies for the mail noise, but I can't seem to reproduce any failures here on
371c45b569(Merge branch 'dk/help-all' into seen, 2025-08-04), which is the latest seen I can find.
When I report a public CI failure, I'd try to give an exact URL, but otherwise the failure would have been seen in my local environment, and because I tend to refrain from pushing out a know-to-be-broken tree, it is unsurprising if 371c45b569 did not fail.
That commit does not have lo/repo-info, I suspect. I didn't know exactly which topic was causing, but the error was observed when "repo --help-all" was given, so perhaps some interactions between these two topics.
Thanks.
Quoted 14 lines · Junio C Hamano
Quoted 3 lines · "D. Ben Knoble
With apologies for the mail noise, but I can't seem to reproduce any failures here on
371c45b569(Merge branch 'dk/help-all' into seen, 2025-08-04), which is the latest seen I can find.When I report a public CI failure, I'd try to give an exact URL, but otherwise the failure would have been seen in my local environment, and because I tend to refrain from pushing out a know-to-be-broken tree, it is unsurprising if
371c45b569did not fail.
Quoted 4 lines
That commit does not have lo/repo-info, I suspect. I didn't know exactly which topic was causing, but the error was observed when "repo --help-all" was given, so perhaps some interactions between these two topics.
I did also try a merge between 371c… and lo/repo-info with similar success. :/
If you happen to find such a faulty tree again, would you consider publishing a broken branch I can fetch?
Quoted 9 lines
When I report a public CI failure, I'd try to give an exact URL, but otherwise the failure would have been seen in my local environment, and because I tend to refrain from pushing out a know-to-be-broken tree, it is unsurprising if
371c45b569did not fail.That commit does not have lo/repo-info, I suspect. I didn't know exactly which topic was causing
Yeah, I forgot to check the CI before I sent the last version. My bad, I'm sorry for this. I'll be more careful next time.
Quoted 3 lines
but the error was observed when
"repo --help-all" was given, so perhaps some interactions between these two topics.
However, after merging my local repo-info-v7 onto 371c45b569 in my local environment, I can execute git repo --help-all without any errors. I also pushed this merge to GitHub [1], the only fails were directly related to my branch (some tests that I wrote and some leaks).
[1] https://github.com/lucasoshiro/git/actions/runs/16759427895/job/47450548740
Quoted 12 lines · Lucas Seiki Oshiro
Quoted 8 lines
When I report a public CI failure, I'd try to give an exact URL, but otherwise the failure would have been seen in my local environment, and because I tend to refrain from pushing out a know-to-be-broken tree, it is unsurprising if
371c45b569did not fail.That commit does not have lo/repo-info, I suspect. I didn't know exactly which topic was causing
Yeah, I forgot to check the CI before I sent the last version. My bad, I'm sorry for this. I'll be more careful next time.
Quoted 6 lines
Quoted 3 lines
but the error was observed when
"repo --help-all" was given, so perhaps some interactions between these two topics.However, after merging my local repo-info-v7 onto
371c45b569in my local environment, I can executegit repo --help-allwithout any errors.
The breakage reported was about some leaks, and not about "does the end-user observe any error when the command runs?".
Quoted 3 lines
I
also pushed this merge to GitHub [1], the only fails were directly related to my branch (some tests that I wrote and some leaks).
And it is not surprising, when these two were merged to 'seen', leaks in your topic were triggering failures.