What's cooking in git.git (Aug 2025, #05; Mon, 11)

What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Junio C Hamano]

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).

Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors.  Some
repositories have only a subset of branches.

With maint, master, next, seen, todo:

	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-scm/git/

With all the integration branches and topics broken out:

	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/

Release tarballs are available at:

	https://www.kernel.org/pub/software/scm/git/

--------------------------------------------------
[New Topics]

* rs/for-each-ref-start-after-marker-fix (2025-08-09) 1 commit
  (merged to 'next' on 2025-08-09 at 44788822b0)
 + for-each-ref: call --start-after argument "marker"

 Hotfix.

 Will merge to 'master'.
 source: <1a32a666-fcf4-4f05-a468-2afa07fa0e2d@web.de>


* rs/merge-compact-summary (2025-08-09) 1 commit
  (merged to 'next' on 2025-08-09 at 924127e9c0)
 + merge: don't document non-existing --compact-summary argument

 Hotfix.

 Will merge to 'master'.
 source: <890631d1-4e3e-4ea5-8f58-371fadf2b1b3@web.de>


* ac/deglobal-fmt-merge-log-config (2025-08-10) 2 commits
 - builtin/fmt-merge-msg: stop depending on 'the_repository'
 - environment: remove the global variable 'merge_log_config'

 source: <cover.1754868681.git.ayu.chandekar@gmail.com>


* jc/longer-disambiguation-fix (2025-08-11) 1 commit
 - abbrev: allow extending beyond 20 chars to disambiguate

 source: <xmqqzfc51xvk.fsf@gitster.g>

--------------------------------------------------
[Cooking]

* dl/push-missing-object-error (2025-08-08) 3 commits
 - remote.c: convert if-else ladder to switch
 - remote.c: remove BUG in show_push_unqualified_ref_name_error()
 - t5516: remove surrounding empty lines in test bodies

 "git push" had a code path that led to BUG() but it should have
 been a die(), as it is a response to a usual but invalid end-user
 action to attempt pushing an object that does not exist.

 Will merge to 'next'.
 cf. <xmqqo6spiyqp.fsf@gitster.g>
 source: <cover.1754637849.git.liu.denton@gmail.com>


* ja/doc-lint-sections-and-synopsis (2025-08-11) 6 commits
 - doc lint: check that synopsis manpages have synopsis inlines
 - doc:git-for-each-ref: fix styling and typos
 - doc: check for absence of the form --[no-]parameter
 - doc: check for absence of multiple terms in each entry of desc list
 - doc: check well-formedness of delimited sections
 - doc: test linkgit macros for well-formedness

 Doc lint updates to encourage the newer and easier-to-use
 `synopsis` format, with fixes to a handful of existing uses.

 Will merge to 'next'?
 source: <pull.1945.v3.git.1754945600.gitgitgadget@gmail.com>


* js/rebase-i-allow-drop-on-a-merge (2025-08-06) 1 commit
  (merged to 'next' on 2025-08-07 at bc44e9dc1b)
 + rebase -i: permit 'drop' of a merge commit

 During interactive rebase, using 'drop' on a merge commit lead to
 an error, which was incorrect.

 Will cook in 'next'.
 source: <37f6e34c-91aa-4e55-88e1-019d2e042df3@kdbg.org>


* ms/refs-list (2025-08-05) 6 commits
 - t: add test for git refs list subcommand
 - t6300: refactor tests to be shareable
 - builtin/refs: add list subcommand
 - builtin/for-each-ref: factor out core logic into a helper
 - builtin/for-each-ref: align usage string with the man page
 - doc: factor out common option

 The "list" subcommand of "git refs" acts as a front-end for
 "git for-each-ref".

 Comments?
 source: <20250805092758.5321-1-meetsoni3017@gmail.com>


* kh/doc-git-log-markup-fix (2025-08-08) 1 commit
 - doc: git-log: fix description list

 Doc update.

 Will merge to 'next'.
 source: <aaa1734189ec8bab7cfa0965132e3d8e5909b1af.1754660514.git.code@khaugsbakk.name>


* ly/changed-path-traversal-with-magic-pathspec (2025-08-10) 1 commit
 - bloom: enable bloom filter with wildcard pathspec in revision traversal

 Revision traversal limited with pathspec, like "git log dir/*",
 used to ignore changed-paths Bloom filter when the pathspec
 contained wildcards; now they take advantage of the filter when
 they can.

 Will merge to 'next'?
 source: <20250811060137.75135-1-yldhome2d2@gmail.com>


* ps/commit-graph-wo-globals (2025-08-07) 10 commits
 - commit-graph: stop passing in redundant repository
 - commit-graph: stop using `the_repository`
 - commit-graph: stop using `the_hash_algo`
 - commit-graph: refactor `parse_commit_graph()` to take a repository
 - commit-graph: store the hash algorithm instead of its length
 - commit-graph: stop using `the_hash_algo` via macros
 - commit-graph: fix sign comparison warnings
 - commit-graph: fix type for some write options
 - commit-graph: stop using signed integers to count Bloom filters
 - trace2: introduce function to trace unsigned integers

 Remove dependency on the_repository and other globals from the
 commit-graph code, and other changes unrelated to de-globaling.

 Will merge to 'next'?
 source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>


* tc/t0450-harden (2025-08-08) 2 commits
 . t0450: add allowlist for builtins with missing .adoc
 . t0450: fix test for out-of-tree builds

 Test updates.

 Expecting a reroll?
 cf. <xmqq7bzdfoxe.fsf@gitster.g>
 source: <20250808095943.3312265-1-toon@iotcl.com>


* gh/git-jump-pathname-with-sp (2025-08-11) 1 commit
 - git-jump: make `diff` work with filenames containing spaces

 "git jump" (in contrib/) fails to parse the diff header correctly
 when a file has a space in its name, which has been corrected.

 Will merge to 'next'?
 source: <pull.1950.v2.git.1754913323810.gitgitgadget@gmail.com>


* jc/diff-no-index-in-subdir (2025-08-09) 1 commit
 - diff: --no-index should ignore the worktree

 "git diff --no-index" run inside a subdirectory under control of a
 Git repository operated at the top of the working tree and stripped
 the prefix from the output, and oddballs like "-" (stdin) did not
 work correctly because of it.  Correct the set-up by undoing what
 the set-up sequence did to cwd and prefix.

 Will merge to 'next'?
 source: <xmqq1ppk58ob.fsf@gitster.g>


* je/doc-rebase (2025-08-11) 6 commits
 - fixup! doc: git-rebase: update discussion of internals
 - doc: git-rebase: update discussion of internals
 - doc: git-rebase: move --onto explanation down
 - doc: git rebase: clarify arguments syntax
 - doc: git rebase: dedup merge conflict discussion
 - doc: git-rebase: start with an example

 Documentation for "git rebase" has been updated.

 Comments?
 source: <pull.1949.v6.git.1754949075.gitgitgadget@gmail.com>


* rj/t6137-cygwin-fix (2025-08-08) 1 commit
 - t6137-*.sh: fix test failure on cygwin

 Test fix for breakage introduced in Git 2.50.

 Will merge to 'next'.
 source: <5514f2fd-3307-42c8-97ac-bc2147a7ba41@ramsayjones.plus.com>


* ps/reftable-libgit2-cleanup (2025-08-04) 6 commits
 - reftable/stack: handle outdated stacks when compacting
 - 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: <20250804-pks-reftable-fixes-for-libgit2-v2-0-fef06209a984@pks.im>


* tc/diff-tree-max-depth (2025-08-07) 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: <20250807-toon-max-depth-v2-0-50b7e5c81665@iotcl.com>


* dk/help-all (2025-08-03) 3 commits
 - builtin: also setup gently for --help-all
 - parse-options: refactor flags for usage_with_options_internal
 - 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.

 Comments?
 source: <20250803012613.54086-1-ben.knoble+github@gmail.com>


* lc/rebase-trailer (2025-08-03) 2 commits
 - rebase: support --trailer
 - trailer: append trailers in-process and drop the fork to `interpret-trailers`

 Expecting a reroll.
 cf. <198826af571.62b85cb31711042.2415806544948206668@linux.beauty>
 source: <20250803150059.402017-1-me@linux.beauty>


* ly/diff-name-only-with-diff-from-content (2025-08-07) 1 commit
 - diff: ensure consistent diff behavior with ignore options

 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.

 Will merge to 'next'?
 source: <20250808033019.78817-1-yldhome2d2@gmail.com>


* rs/describe-with-prio-queue (2025-08-03) 2 commits
  (merged to 'next' on 2025-08-07 at 5ebcaaf8b8)
 + describe: use prio_queue_replace()
 + describe: use prio_queue

 "git describe" has been optimized by using better data structure.

 Will cook in 'next'.
 source: <36d5b59a-a99a-4a6f-b637-dfb0b760660f@web.de>


* ps/object-store-midx-dedup-info (2025-08-11) 11 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: simplify calling `link_alt_odb_entry()`
 - odb: return newly created in-memory sources
 - odb: consistently use "dir" to refer to alternate's directory
 - 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: <20250811-b4-pks-midx-deduplicate-source-info-v3-0-e442bdf2b4ad@pks.im>


* 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: <20250731225433.4028872-1-gitster@pobox.com>


* 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: <20250801220423.1230969-1-gitster@pobox.com>


* 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: <20250728190520.10962-1-amonakov@ispras.ru>


* ps/remote-rename-fix (2025-07-31) 7 commits
  (merged to 'next' on 2025-08-07 at 227d2faf29)
 + 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 cook in 'next'.
 source: <20250731-pks-remote-rename-improvements-v2-0-dda6f083674d@pks.im>


* ag/send-email-imap-sent (2025-08-11) 3 commits
 - fixup! send-email: enable copying emails to IMAP folder without actually sending them
 - send-email: enable copying emails to IMAP folder without actually sending them
 - 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.

 Comments?
 source: <PN3PR01MB9597EC4C5DF97943587AEEB4B85FA@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>


* en/ort-rename-fixes (2025-08-06) 7 commits
 - merge-ort: fix directory rename on top of source of other rename/delete
 - merge-ort: fix incorrect file handling
 - merge-ort: clarify the interning of strings in opt->priv->path
 - 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.

 Will merge to 'next'?
 source: <pull.1943.v3.git.1754522122.gitgitgadget@gmail.com>


* ps/reflog-migrate-fixes (2025-08-05) 9 commits
  (merged to 'next' on 2025-08-07 at 8068e2ad68)
 + 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 cook in 'next'.
 source: <20250806-pks-reflog-append-v6-0-a50839653766@pks.im>


* 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: <pull.1941.v2.git.1752716054.gitgitgadget@gmail.com>


* 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

 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: <cover.1753975294.git.phillip.wood@dunelm.org.uk>


* ua/t1517-short-help-tests (2025-08-07) 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.

 Will merge to 'next'.
 source: <20250808010651.591906-1-usmanakinyemi202@gmail.com>


* tc/last-modified (2025-08-05) 4 commits
 - fixup! last-modified: new subcommand to show when files were last modified
 - last-modified: use Bloom filters when available
 - 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.
 source: <20250730175510.987383-1-toon@iotcl.com>


* lo/repo-info (2025-08-07) 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.

 Expecting a reroll?
 source: <20250807150239.6987-1-lucasseikioshiro@gmail.com>


* 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: <cover.1752882401.git.ayu.chandekar@gmail.com>


* 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. <20250530065034.GC1321283@coredump.intra.peff.net>
 source: <cover.1748473122.git.me@ttaylorr.com>


* 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: <20250731072401.3817074-1-christian.couder@gmail.com>

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Patrick Steinhardt]

On Tue, Aug 12, 2025 at 01:29:45AM -0700, Junio C Hamano wrote:
> * ms/refs-list (2025-08-05) 6 commits
>  - t: add test for git refs list subcommand
>  - t6300: refactor tests to be shareable
>  - builtin/refs: add list subcommand
>  - builtin/for-each-ref: factor out core logic into a helper
>  - builtin/for-each-ref: align usage string with the man page
>  - doc: factor out common option
> 
>  The "list" subcommand of "git refs" acts as a front-end for
>  "git for-each-ref".
> 
>  Comments?
>  source: <20250805092758.5321-1-meetsoni3017@gmail.com>

I've reviewed this version and am happy with the result. From my point
of view it's ready to cook in 'next'.

> * ps/commit-graph-wo-globals (2025-08-07) 10 commits
>  - commit-graph: stop passing in redundant repository
>  - commit-graph: stop using `the_repository`
>  - commit-graph: stop using `the_hash_algo`
>  - commit-graph: refactor `parse_commit_graph()` to take a repository
>  - commit-graph: store the hash algorithm instead of its length
>  - commit-graph: stop using `the_hash_algo` via macros
>  - commit-graph: fix sign comparison warnings
>  - commit-graph: fix type for some write options
>  - commit-graph: stop using signed integers to count Bloom filters
>  - trace2: introduce function to trace unsigned integers
> 
>  Remove dependency on the_repository and other globals from the
>  commit-graph code, and other changes unrelated to de-globaling.
> 
>  Will merge to 'next'?
>  source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>

I don't intend to reroll this series for now. As long as you are happy
with the signedness-related patches I think this should be ready.

> * tc/t0450-harden (2025-08-08) 2 commits
>  . t0450: add allowlist for builtins with missing .adoc
>  . t0450: fix test for out-of-tree builds
> 
>  Test updates.
> 
>  Expecting a reroll?
>  cf. <xmqq7bzdfoxe.fsf@gitster.g>
>  source: <20250808095943.3312265-1-toon@iotcl.com>

Toon is currently out of office, so this'll take a while to be rerolled.
I'll have a look at whether I can reconstruct the seemingly-missing
file.

> * en/ort-rename-fixes (2025-08-06) 7 commits
>  - merge-ort: fix directory rename on top of source of other rename/delete
>  - merge-ort: fix incorrect file handling
>  - merge-ort: clarify the interning of strings in opt->priv->path
>  - 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.
> 
>  Will merge to 'next'?
>  source: <pull.1943.v3.git.1754522122.gitgitgadget@gmail.com>

The patch series looks reasonable to me, but that's basically just going
by the commit messages. I wouldn't claim to really understand our merge
machinery, so my opinion is only of limited use.

Patrick

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Taylor Blau]

On Tue, Aug 12, 2025 at 02:52:41PM +0200, Patrick Steinhardt wrote:
> > * ps/commit-graph-wo-globals (2025-08-07) 10 commits
> >  - commit-graph: stop passing in redundant repository
> >  - commit-graph: stop using `the_repository`
> >  - commit-graph: stop using `the_hash_algo`
> >  - commit-graph: refactor `parse_commit_graph()` to take a repository
> >  - commit-graph: store the hash algorithm instead of its length
> >  - commit-graph: stop using `the_hash_algo` via macros
> >  - commit-graph: fix sign comparison warnings
> >  - commit-graph: fix type for some write options
> >  - commit-graph: stop using signed integers to count Bloom filters
> >  - trace2: introduce function to trace unsigned integers
> >
> >  Remove dependency on the_repository and other globals from the
> >  commit-graph code, and other changes unrelated to de-globaling.
> >
> >  Will merge to 'next'?
> >  source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>
>
> I don't intend to reroll this series for now. As long as you are happy
> with the signedness-related patches I think this should be ready.

I am still not sold on the first four of these patches, and I share
Junio's concern[1] that the "int -> unsigned int" changes are not well
justified.

As a practical concern, the "max_commits" and "size_mult" values should
never come even close to INT_MAX, so I am not sure that the wider range
is giving us all that much. I am a little more convinced by the Bloom
filter changes, but since they are purely for debugging and also
exceedingly unlikely to exceed the signed INT_MAX, I do not think they
are absolutely necessary.

That said, I don't feel strongly enough about the lack of justification
here to hold up this series[^2], so I am fine with it moving forward if
both you and Junio are happy with it as-is. But I am left wanting a
stronger justification for the first half of the changes.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/xmqqpld6kb4t.fsf@gitster.g

[^2]: I don't want to waste the list's time debating a signed-ness
conversion when we have much bigger fish to fry, but I also do not want
to deviate too far from our usual standards, either.

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Tue, Aug 12, 2025 at 01:29:45AM -0700, Junio C Hamano wrote:
>> * ms/refs-list (2025-08-05) 6 commits
>>  - t: add test for git refs list subcommand
>>  - t6300: refactor tests to be shareable
>>  - builtin/refs: add list subcommand
>>  - builtin/for-each-ref: factor out core logic into a helper
>>  - builtin/for-each-ref: align usage string with the man page
>>  - doc: factor out common option
>> 
>>  The "list" subcommand of "git refs" acts as a front-end for
>>  "git for-each-ref".
>> 
>>  Comments?
>>  source: <20250805092758.5321-1-meetsoni3017@gmail.com>
>
> I've reviewed this version and am happy with the result. From my point
> of view it's ready to cook in 'next'.

I've looked at it, too.  Thanks for a review.

>> * ps/commit-graph-wo-globals (2025-08-07) 10 commits
>>  - commit-graph: stop passing in redundant repository
>>  - commit-graph: stop using `the_repository`
>>  - commit-graph: stop using `the_hash_algo`
>>  - commit-graph: refactor `parse_commit_graph()` to take a repository
>>  - commit-graph: store the hash algorithm instead of its length
>>  - commit-graph: stop using `the_hash_algo` via macros
>>  - commit-graph: fix sign comparison warnings
>>  - commit-graph: fix type for some write options
>>  - commit-graph: stop using signed integers to count Bloom filters
>>  - trace2: introduce function to trace unsigned integers
>> 
>>  Remove dependency on the_repository and other globals from the
>>  commit-graph code, and other changes unrelated to de-globaling.
>> 
>>  Will merge to 'next'?
>>  source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>
>
> I don't intend to reroll this series for now. As long as you are happy
> with the signedness-related patches I think this should be ready.

Heh, I am not obviously happy.  I don't have time to go in myself
and fix them, though.

>> * tc/t0450-harden (2025-08-08) 2 commits
>>  . t0450: add allowlist for builtins with missing .adoc
>>  . t0450: fix test for out-of-tree builds
>> 
>>  Test updates.
>> 
>>  Expecting a reroll?
>>  cf. <xmqq7bzdfoxe.fsf@gitster.g>
>>  source: <20250808095943.3312265-1-toon@iotcl.com>
>
> Toon is currently out of office, so this'll take a while to be rerolled.
> I'll have a look at whether I can reconstruct the seemingly-missing
> file.

I saw your patch.  I'll queue it separately on top.  As we won't be
moving new things beyond 'seen' for at least another week anyway, we
are not in a hurry ;-)

>> * en/ort-rename-fixes (2025-08-06) 7 commits
>>  - merge-ort: fix directory rename on top of source of other rename/delete
>>  - merge-ort: fix incorrect file handling
>>  - merge-ort: clarify the interning of strings in opt->priv->path
>>  - 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.
>> 
>>  Will merge to 'next'?
>>  source: <pull.1943.v3.git.1754522122.gitgitgadget@gmail.com>
>
> The patch series looks reasonable to me, but that's basically just going
> by the commit messages. I wouldn't claim to really understand our merge
> machinery, so my opinion is only of limited use.

Thanks.  These looked OK to me, too.

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Jean-Noël AVILA]

On Tuesday, 12 August 2025 10:29:45 CEST Junio C Hamano wrote:
> 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).
> 
> 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.
> 
> * ja/doc-lint-sections-and-synopsis (2025-08-11) 6 commits
>  - doc lint: check that synopsis manpages have synopsis inlines
>  - doc:git-for-each-ref: fix styling and typos
>  - doc: check for absence of the form --[no-]parameter
>  - doc: check for absence of multiple terms in each entry of desc list
>  - doc: check well-formedness of delimited sections
>  - doc: test linkgit macros for well-formedness
> 
>  Doc lint updates to encourage the newer and easier-to-use
>  `synopsis` format, with fixes to a handful of existing uses.
> 
>  Will merge to 'next'?
>  source: <pull.1945.v3.git.1754945600.gitgitgadget@gmail.com>
> 
> 

These patches are designed to not raise false positives, trading it for 
letting true positives pass through. For instance, the "synopsis" patch cannot 
catch keywords which are just one word.

 If possible, I'd like to see how they behave against upcoming documentation 
changes described in this "cooking". This is in order to not have to revert 
them at some point.

Jean-Noël

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Junio C Hamano]

Jean-Noël AVILA <jn.avila@free.fr> writes:

> These patches are designed to not raise false positives, trading it for 
> letting true positives pass through. For instance, the "synopsis" patch cannot 
> catch keywords which are just one word.
>
> If possible, I'd like to see how they behave against upcoming documentation 
> changes described in this "cooking". This is in order to not have to revert 
> them at some point.

The topic being in 'seen' would test other topics in-flight
concurrently with this topic; avoiding false positives while trying
to minimize false negatives is very much appreciated.

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Patrick Steinhardt]

On Tue, Aug 12, 2025 at 10:41:46AM -0400, Taylor Blau wrote:
> On Tue, Aug 12, 2025 at 02:52:41PM +0200, Patrick Steinhardt wrote:
> > > * ps/commit-graph-wo-globals (2025-08-07) 10 commits
> > >  - commit-graph: stop passing in redundant repository
> > >  - commit-graph: stop using `the_repository`
> > >  - commit-graph: stop using `the_hash_algo`
> > >  - commit-graph: refactor `parse_commit_graph()` to take a repository
> > >  - commit-graph: store the hash algorithm instead of its length
> > >  - commit-graph: stop using `the_hash_algo` via macros
> > >  - commit-graph: fix sign comparison warnings
> > >  - commit-graph: fix type for some write options
> > >  - commit-graph: stop using signed integers to count Bloom filters
> > >  - trace2: introduce function to trace unsigned integers
> > >
> > >  Remove dependency on the_repository and other globals from the
> > >  commit-graph code, and other changes unrelated to de-globaling.
> > >
> > >  Will merge to 'next'?
> > >  source: <20250807-b4-pks-commit-graph-wo-the-repository-v3-0-82edef830a1e@pks.im>
> >
> > I don't intend to reroll this series for now. As long as you are happy
> > with the signedness-related patches I think this should be ready.
> 
> I am still not sold on the first four of these patches, and I share
> Junio's concern[1] that the "int -> unsigned int" changes are not well
> justified.
> 
> As a practical concern, the "max_commits" and "size_mult" values should
> never come even close to INT_MAX, so I am not sure that the wider range
> is giving us all that much. I am a little more convinced by the Bloom
> filter changes, but since they are purely for debugging and also
> exceedingly unlikely to exceed the signed INT_MAX, I do not think they
> are absolutely necessary.
> 
> That said, I don't feel strongly enough about the lack of justification
> here to hold up this series[^2], so I am fine with it moving forward if
> both you and Junio are happy with it as-is. But I am left wanting a
> stronger justification for the first half of the changes.

Fair. I don't want to spend too much time on this signedness topic,
either. So I'd go with either:

  - Taking the signedness patches as-is. They don't regress the status
    quo and allow us to warn about future unintentional signedness bugs,
    even though the fixes are mostly of theoretical value.

  - I drop the signedness-conversion patches altogether.

The more important part for me is to get the second half of patches
merged anyway. So while I think that the first half of patches are nice
to have, I can live with dropping them.

Let me know which of these options you prefer.

Patrick

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Taylor Blau]

On Wed, Aug 13, 2025 at 09:06:33AM +0200, Patrick Steinhardt wrote:
> Fair. I don't want to spend too much time on this signedness topic,
> either. So I'd go with either:
>
>   - Taking the signedness patches as-is. They don't regress the status
>     quo and allow us to warn about future unintentional signedness bugs,
>     even though the fixes are mostly of theoretical value.
>
>   - I drop the signedness-conversion patches altogether.
>
> The more important part for me is to get the second half of patches
> merged anyway. So while I think that the first half of patches are nice
> to have, I can live with dropping them.

I'd personally lean towards the latter, and drop those patches for now.
I think practically speaking that equates to taking patches in the range
[5, 10].

To be clear, I am not opposed to the signedness changes entirely, but I
do think that they merit a little more discussion and thought around
what our general practices should be here.

If you want to resurrect those as a separate topic later on, I'd be
happy to discuss them then.

Thanks,
Taylor

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> On Wed, Aug 13, 2025 at 09:06:33AM +0200, Patrick Steinhardt wrote:
>> Fair. I don't want to spend too much time on this signedness topic,
>> either. So I'd go with either:
>>
>>   - Taking the signedness patches as-is. They don't regress the status
>>     quo and allow us to warn about future unintentional signedness bugs,
>>     even though the fixes are mostly of theoretical value.
>>
>>   - I drop the signedness-conversion patches altogether.
>>
>> The more important part for me is to get the second half of patches
>> merged anyway. So while I think that the first half of patches are nice
>> to have, I can live with dropping them.
>
> I'd personally lean towards the latter, and drop those patches for now.
> I think practically speaking that equates to taking patches in the range
> [5, 10].

Yeah, that is much simpler.  That way, we do not add more commits in
"git log" that people may find later and mistakenly think that the
project had consensus to encourage the use of unsigned when signed
and narrower integer would do fine, and we won't have to see
misguided false positives from -Wsign-compare.  We are better off
without these changes.

Re: What's cooking in git.git (Aug 2025, #05; Mon, 11)

[Patrick Steinhardt]

On Wed, Aug 13, 2025 at 07:55:44AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
> 
> > On Wed, Aug 13, 2025 at 09:06:33AM +0200, Patrick Steinhardt wrote:
> >> Fair. I don't want to spend too much time on this signedness topic,
> >> either. So I'd go with either:
> >>
> >>   - Taking the signedness patches as-is. They don't regress the status
> >>     quo and allow us to warn about future unintentional signedness bugs,
> >>     even though the fixes are mostly of theoretical value.
> >>
> >>   - I drop the signedness-conversion patches altogether.
> >>
> >> The more important part for me is to get the second half of patches
> >> merged anyway. So while I think that the first half of patches are nice
> >> to have, I can live with dropping them.
> >
> > I'd personally lean towards the latter, and drop those patches for now.
> > I think practically speaking that equates to taking patches in the range
> > [5, 10].
> 
> Yeah, that is much simpler.  That way, we do not add more commits in
> "git log" that people may find later and mistakenly think that the
> project had consensus to encourage the use of unsigned when signed
> and narrower integer would do fine, and we won't have to see
> misguided false positives from -Wsign-compare.  We are better off
> without these changes.

Okay, will send a new version accordingly.

Thanks!

Patrick