What's cooking in git.git (Dec 2025, #03)

What's cooking in git.git (Dec 2025, #03)

[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]

* jt/repo-struct-more-objinfo (2025-12-09) 6 commits
 - builtin/repo: add object disk size info to structure table
 - builtin/repo: add disk size info to keyvalue stucture output
 - builtin/repo: add inflated object info to structure table
 - builtin/repo: add inflated object info to keyvalue structure output
 - builtin/repo: humanise count values in structure output
 - builtin/repo: group per-type object values into struct

 More object database related information are shown in "git repo
 structure" output.

 Comments?
 source: <20251209225820.2861276-1-jltobler@gmail.com>


* jc/c99-fam (2025-12-11) 1 commit
 - 3.0: require C99 flexible-array member syntax

 Require C99 style flexible array member support after Git 3.0
 boundary.

 Comments?
 source: <xmqqbjk5e32q.fsf@gitster.g>


* jc/macports-darwinports (2025-12-10) 1 commit
 - Makefile: help macOS novices by mentioning MacPorts

 Makefile in-comment doc update.

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


* rs/macos-iconv-workaround (2025-12-09) 1 commit
 - config.mak.uname: use iconv from Homebrew on macOS

 Workaround that "iconv" shipped as part of macOS, which is broken
 handling ISO-2022 encoded strings.

 Will merge to 'next'?
 source: <16efc726-34be-44f5-aa92-4e82b663ab3d@web.de>


* rs/replay-wrong-onto-fix (2025-12-11) 2 commits
 - replay: move onto NULL check before first use
 - Merge branch 'sa/replay-atomic-ref-updates' into rs/replay-wrong-onto-fix

 "git replay --onto=<commit> ...", when <commit> is mistyped,
 started to segfault with recent change, which has been corrected.

 Will merge to 'next'.
 source: <9db2b913-b5d6-4617-b079-b4612eaa2b97@web.de>


* tc/memzero-array (2025-12-10) 3 commits
 - contrib/coccinelle: pass include paths to spatch(1)
 - git-compat-util: introduce MEMZERO_ARRAY() macro
 - Merge branch 'tc/last-modified-active-paths-optimization' into tc/memzero-array
 (this branch uses tc/last-modified-active-paths-optimization.)

 MEMZERO_ARRAY() helper is introduced to avoid clearing only the
 first N bytes of an N-element array whose elements are larger than
 a byte.

 Will merge to 'next'?
 cf. <aTpieqFoMmZiSzWS@pks.im>
 source: <20251210-toon-cocci-memzero-v1-0-ae916a79065b@iotcl.com>

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

* jc/capability-leak (2025-12-06) 1 commit
  (merged to 'next' on 2025-12-10 at cfe8ce92b1)
 + connect: plug protocol capability leak

 Leakfix.

 Will merge to 'master'.
 source: <xmqqfr9mnbu9.fsf@gitster.g>


* kh/doc-replay-updates (2025-12-07) 3 commits
 - doc: replay: link section using markup
 - doc: replay: document --contained
 - doc: replay: mention no output on conflicts

 "git replay" documentation updates.

 Expecting a (hopefully small and final) reroll.
 cf. <39b57721-ab9e-489d-a382-16d9fe94c300@app.fastmail.com>
 source: <CV_replay_conflict.101@msgid.xyz>


* lo/repo-info-keys (2025-12-09) 3 commits
 - repo: add new flag --keys to git-repo-info
 - repo: add a default output format to enum output_format
 - Merge branch 'lo/repo-struct-z' into lo/repo-info-keys
 (this branch uses lo/repo-struct-z.)

 "git repo info" learns "--keys" action to list known keys.

 Comments?
 source: <20251209194616.61620-1-lucasseikioshiro@gmail.com>


* kh/doc-pre-commit-fix (2025-12-07) 1 commit
  (merged to 'next' on 2025-12-10 at f21f000140)
 + doc: join default pre-commit paragraphs

 Docfix.

 Will merge to 'master'.
 source: <pre-commit_when_enabled.10a@msgid.xyz>


* kh/doc-send-email-paragraph-fix (2025-12-08) 1 commit
  (merged to 'next' on 2025-12-10 at 674ac2bdf7)
 + doc: send-email: fix broken list continuation

 Docfix.

 Will merge to 'master'.
 source: <send-email_list_contin.112@msgid.xyz>


* mh/doc-config-gui-gcwarning (2025-12-08) 1 commit
  (merged to 'next' on 2025-12-10 at 15d6df9a04)
 + config: document 'gui.GCWarning'

 Docfix.

 Will merge to 'master'.
 source: <20251208190400.64920-1-matthewhughes934@gmail.com>


* ps/odb-alternates-object-sources (2025-12-11) 8 commits
  (merged to 'next' on 2025-12-12 at 1dd061c0dc)
 + odb: write alternates via sources
 + odb: read alternates via sources
 + odb: drop forward declaration of `read_info_alternates()`
 + odb: remove mutual recursion when parsing alternates
 + odb: stop splitting alternate in `odb_add_to_alternates_file()`
 + odb: move computation of normalized objdir into `alt_odb_usable()`
 + odb: resolve relative alternative paths when parsing
 + odb: refactor parsing of alternates to be self-contained

 Code refactoring around alternate object store.

 Will merge to 'master'.
 source: <20251211-b4-pks-odb-alternates-via-source-v3-0-00e3f54d07ba@pks.im>


* ps/repack-avoid-noop-midx-rewrite (2025-12-10) 3 commits
 - midx-write: skip rewriting MIDX with `--stdin-packs` unless needed
 - midx-write: extract function to test whether MIDX needs updating
 - midx: fix `BUG()` when getting preferred pack without a reverse index

 Even when there is no changes in the packfile and no need to
 recompute bitmaps, "git repack" recomputed and updated the MIDX
 file, which has been corrected.

 Comments?
 source: <20251210-pks-skip-noop-rewrite-v2-0-f813a9e44f28@pks.im>


* sb/doc-update-ref-markup-fix (2025-12-08) 1 commit
 - doc: fix `update-ref` `symref-create` formatting

 Doc mark-up fix.

 Will merget to 'next'.
 source: <pull.2123.git.git.1765261419802.gitgitgadget@gmail.com>


* ap/packfile-promisor-object-optim (2025-12-08) 2 commits
 - packfile: skip hash checks in add_promisor_object()
 - object: apply skip_hash and discard_tree optimizations to unknown blobs too

 The code path that enumerates promisor objects have been optimized
 to skip pointlessly parsing blob objects.

 Comments?
 source: <20251209014900.402637-1-aplattner@nvidia.com>


* je/doc-pull (2025-12-03) 1 commit
  (merged to 'next' on 2025-12-05 at 601711e5f2)
 + doc: git-pull: fix 'git --rebase abort' typo

 Doc fixup.

 Will merge to 'master'.
 source: <pull.2015.git.1764776095597.gitgitgadget@gmail.com>


* js/last-modified-with-sparse-checkouts (2025-11-29) 1 commit
  (merged to 'next' on 2025-12-05 at f1d5abdd14)
 + last-modified: support sparse checkouts

 "git last-modified" used to mishandle "--" to mark the beginning of
 pathspec, which has been corrected.

 Will merge to 'master'.
 source: <pull.2013.git.1764423826908.gitgitgadget@gmail.com>


* kh/advise-w-git-help-in-branch (2025-12-02) 1 commit
  (merged to 'next' on 2025-12-05 at 3b7b03150e)
 + branch: advice using git-help(1) instead of man(1)

 A help message from "git branch" now mentions "git help" instead of
 "man" when suggesting to read some documentation.

 Will merge to 'master'.
 source: <V2_advice_git-help.53@msgid.xyz>


* lo/repo-struct-z (2025-12-04) 3 commits
  (merged to 'next' on 2025-12-06 at 4f602e14d8)
 + repo: add -z as an alias for --format=nul to git-repo-structure
 + repo: use [--format=... | -z] instead of [-z] in git-repo-info synopsis
 + repo: remove blank line from Documentation/git-repo.adoc
 (this branch is used by lo/repo-info-keys.)

 "git repo struct" learned to take "-z" as a synonym to "--format=nul".

 Will merge to 'master'.
 cf. <aTK9X6ptrqs_9agD@pks.im>
 source: <20251204210843.79411-1-lucasseikioshiro@gmail.com>


* tc/meson-cross-compile-fix (2025-12-03) 3 commits
  (merged to 'next' on 2025-12-05 at c45b57ca74)
 + meson: use is_cross_build() where possible
 + meson: only detect ICONV_OMITS_BOM if possible
 + meson: ignore subprojects/.wraplock

 Build fix.

 Will merge to 'master'.
 source: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com>


* je/doc-data-model (2025-12-02) 1 commit
  (merged to 'next' on 2025-12-06 at 3f4935d65f)
 + doc: remove stray text in Git data model

 Docfix.

 Will merge to 'master'.
 source: <pull.2014.git.1764699084703.gitgitgadget@gmail.com>


* ps/odb-misc-fixes (2025-12-10) 3 commits
 - odb: properly close sources before freeing them
 - builtin/gc: fix condition for whether to write commit graphs
 - Merge branch 'ps/object-source-management' into ps/odb-misc-fixes

 Miscellaneous fixes on object database layer.

 Comments?
 source: <20251211-odb-related-fixes-v2-0-bdf875ce51fc@pks.im>


* ps/clar-integers (2025-12-06) 3 commits
 - gitattributes: disable blank-at-eof errors for clar test expectations
 - t/unit-tests: demonstrate use of integer comparison assertions
 - t/unit-tests: update clar to 39f11fe

 Import newer version of "clar", unit testing framework.

 Comments?
 source: <20251206-b4-pks-clar-update-v2-0-9a14b10c1a36@pks.im>


* rs/ban-mktemp (2025-12-06) 5 commits
  (merged to 'next' on 2025-12-09 at d459e9d8dd)
 + compat: remove gitmkdtemp()
 + banned.h: ban mktemp(3)
 + compat: remove mingw_mktemp()
 + compat: use git_mkdtemp()
 + wrapper: add git_mkdtemp()

 Rewrite the only use of "mktemp()" that is subject to TOCTOU race
 and Stop using the insecure "mktemp()" function.

 Will merge to 'master'.
 source: <64e62623-b911-4ddd-a481-05191853c0a6@web.de>


* tb/incremental-midx-part-3.2 (2025-12-06) 17 commits
 - midx: enable reachability bitmaps during MIDX compaction
 - midx: implement MIDX compaction
 - t/helper/test-read-midx.c: plug memory leak when selecting layer
 - midx-write.c: factor fanout layering from `compute_sorted_entries()`
 - midx-write.c: enumerate `pack_int_id` values directly
 - midx-write.c: extract `fill_pack_from_midx()`
 - midx-write.c: introduce `midx_pack_perm()` helper
 - git-compat-util.h: introduce `u32_add()`
 - midx: do not require packs to be sorted in lexicographic order
 - midx-write.c: introduce `struct write_midx_opts`
 - midx-write.c: don't use `pack_perm` when assigning `bitmap_pos`
 - t/t5319-multi-pack-index.sh: fix copy-and-paste error in t5319.39
 - git-multi-pack-index(1): align SYNOPSIS with 'git multi-pack-index -h'
 - git-multi-pack-index(1): remove non-existent incompatibility
 - builtin/multi-pack-index.c: make '--progress' a common option
 - midx: split `get_midx_checksum()` by adding `get_midx_hash()`
 - midx: mark `get_midx_checksum()` arguments as const

 Further work on incremental repacking using MIDX/bitmap

 Expecting a reroll.
 cf. <aTd+fxpflcLuJXDn@nand.local>
 source: <cover.1765053054.git.me@ttaylorr.com>


* yc/histogram-hunk-shift-fix (2025-12-06) 1 commit
 - xdiff: re-diff shifted change groups when using histogram algorithm

 The final clean-up phase of the diff output could turn the result of
 histogram diff algorithm suboptimal, which has been corrected.

 Comments?
 source: <pull.2120.git.git.1765054287938.gitgitgadget@gmail.com>


* jc/completion-no-single-letter-options (2025-12-06) 1 commit
 - completion: clarify support for short options and arguments

 In-code comment update to clarify that single-letter options are
 outside of the scope of command line completion script.

 Comments?
 source: <xmqqzf7vm7b7.fsf@gitster.g>


* tc/last-modified-active-paths-optimization (2025-11-28) 1 commit
  (merged to 'next' on 2025-12-05 at 42c18b607f)
 + last-modified: fix use of uninitialized memory
 (this branch is used by tc/memzero-array.)

 Recent optimization to "last-modified" command introduced use of
 uninitialized block of memory, which has been corrected.

 Will merge to 'master'.
 source: <20251128-toon-big-endian-ci-v1-1-80da0f629c1e@iotcl.com>


* jk/parse-int (2025-11-30) 5 commits
 - fsck: use parse_unsigned_from_buf() for parsing timestamp
 - cache-tree: use parse_int_from_buf()
 - parse: add functions for parsing from non-string buffers
 - parse: prefer bool to int for boolean returns
 - Merge branch 'jk/asan-bonanza' into jk/parse-int

 Introduce a more robust way to parse a decimal integer stored in a
 piece of memory that is not necessarily terminated with NUL (which
 Asan strict-string-check complains even when use of strtol() is
 safe due to varified existence of whitespace after the digits).

 Expecting a reroll.
 cf. <aTFvKOHlm4zfT9dU@pks.im>
 cf. <4d83375b-76e2-4420-80dd-6a04d3201532@gmail.com>
 source: <20251130131351.GA198697@coredump.intra.peff.net>


* js/test-symlink-windows (2025-12-05) 10 commits
 - t7800: work around the MSYS path conversion on Windows
 - t6423: introduce Windows-specific handling for symlinking to /dev/null
 - t1305: skip symlink tests that do not apply to Windows
 - t1006: accommodate for symlink support in MSYS2
 - t0600: fix incomplete prerequisite for a test case
 - t0301: another fix for Windows compatibility
 - t0001: handle `diff --no-index` gracefully
 - mingw: special-case `open(symlink, O_CREAT | O_EXCL)`
 - apply: symbolic links lack a "trustable executable bit"
 - t9700: accommodate for Windows paths

 Prepare test suite for Git for Windows that supports symbolic
 links.

 Comments?
 cf. <xmqqms44cb7p.fsf@gitster.g>
 cf. <xmqqecpgc8wd.fsf@gitster.g>
 source: <pull.2009.v2.git.1764946945.gitgitgadget@gmail.com>


* rs/diff-index-find-copies-harder-optim (2025-11-30) 1 commit
  (merged to 'next' on 2025-12-05 at 539b086bfc)
 + diff-index: don't queue unchanged filepairs with diff_change()

 Halve the memory consumed by artificial filepairs created during
 "git diff --find-copioes-harder", also making the operation run
 faster.

 Will merge to 'master'.
 source: <aa28974b-ec73-4562-bfc8-4745ad58b55a@web.de>


* tc/last-modified-options-cleanup (2025-11-26) 4 commits
 - fixup! last-modified: document option --max-depth
 - last-modified: document how depth is handled better
 - last-modified: document option --max-depth
 - last-modified: handle and document NUL termination

 The "-z" and "--max-depth" documentation (and implementation of
 "-z") in the "git last-modified" command have been updated.

 Expecting a reroll.
 source: <20251126-toon-last-modified-zzzz-v1-0-608350df0caa@iotcl.com>


* ds/doc-scalar-config (2025-12-01) 5 commits
 - scalar: document config settings
 - scalar: alphabetize and simplify config
 - scalar: remove stale config values
 - scalar: use index.skipHash=true for performance
 - scalar: annotate config file with "set by scalar"

 Documentation updates.

 Expecting a reroll.
 cf. <aS88bnmZXMZCV5oS@pks.im>
 source: <pull.2010.v2.git.1764607847.gitgitgadget@gmail.com>


* pw/replay-drop-empty (2025-11-27) 2 commits
 - replay: drop commits that become empty
 - Merge branch 'ps/history' into pw/replay-drop-empty
 (this branch uses ps/history.)

 "git replay" is taught to drop commits that become empty (not the
 ones that are empty in the original).

 On hold, until the base topic stabilizes.
 source: <8a2a1215306452147cc7b803530ab2429bf57f15.1764260150.git.phillip.wood@dunelm.org.uk>


* sp/shallow-time-boundary (2025-11-23) 1 commit
 - shallow: set borders which are all reachable after clone shallow since

 The set of shallow boundary "git clone --shallow-since" leaves
 contained commits that are not on the boundary, which has been
 corrected.

 Comments?
 source: <pull.2107.v2.git.git.1763926552033.gitgitgadget@gmail.com>


* gf/win32-pthread-cond-init (2025-11-20) 1 commit
  (merged to 'next' on 2025-12-09 at 202516d20c)
 + win32: pthread_cond_init should return a value

 Emulation code clean-up.

 Will merge to 'master'.
 source: <pull.2103.v3.git.git.1763675016637.gitgitgadget@gmail.com>


* kn/ref-location (2025-12-01) 2 commits
 - refs: add GIT_REF_URI to specify reference backend and directory
 - refs: support obtaining ref_store for given dir

 A mechanism to specify what reference backend to use and store
 references in which directory is introduced, which would likely to
 be useful during ref migration.

 Comments?
 source: <20251201-kn-alternate-ref-dir-v3-0-c11b946bc2fa@gmail.com>


* dw/config-global-list (2025-10-09) 4 commits
 - config: keep bailing on unreadable global files
 - config: read global scope via config_sequence
 - config: test home and xdg files in `list --global`
 - cleanup_path: force forward slashes on Windows

 "git config --list --global", unlike "git config --list", did not
 consult both of the two possible per-user sources of the
 configuration files, i.e. $HOME/.gitconfig and the XDG one, which
 has been corrected.

 Expecting a reroll.
 cf. <20251122020047.GB3947@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
 source: <pull.1938.git.1760058849.gitgitgadget@gmail.com>


* ps/object-read-stream (2025-11-23) 20 commits
  (merged to 'next' on 2025-12-09 at c8d645f8ea)
 + streaming: drop redundant type and size pointers
 + streaming: move into object database subsystem
 + streaming: refactor interface to be object-database-centric
 + streaming: move logic to read packed objects streams into backend
 + streaming: move logic to read loose objects streams into backend
 + streaming: make the `odb_read_stream` definition public
 + streaming: get rid of `the_repository`
 + streaming: rely on object sources to create object stream
 + packfile: introduce function to read object info from a store
 + streaming: move zlib stream into backends
 + streaming: create structure for filtered object streams
 + streaming: create structure for packed object streams
 + streaming: create structure for loose object streams
 + streaming: create structure for in-core object streams
 + streaming: allocate stream inside the backend-specific logic
 + streaming: explicitly pass packfile info when streaming a packed object
 + streaming: propagate final object type via the stream
 + streaming: drop the `open()` callback function
 + streaming: rename `git_istream` into `odb_read_stream`
 + Merge branch 'ps/object-source-loose' into ps/object-read-stream

 The "git_istream" abstraction has been revamped to make it easier
 to interface with pluggable object database design.

 Will merge to 'master'.
 source: <20251123-b4-pks-odb-read-stream-v3-0-1a129182822b@pks.im>


* jc/submodule-add (2025-11-15) 1 commit
 - submodule add: sanity check existing .gitmodules

 "git submodule add" to add a submodule under <name> segfaulted,
 when a submodule.<name>.something is already in .gitmodules file
 without defining where its submodule.<name>.path is, which has been
 corrected.

 Comments?
 source: <xmqqv7jacvdq.fsf@gitster.g>


* kn/fix-fetch-backfill-tag-with-batched-ref-updates (2025-11-21) 3 commits
 - fetch: fix failed batched updates skipping operations
 - fetch: fix non-conflicting tags not being committed
 - fetch: extract out reference committing logic

 "git fetch" that involves fetching tags, when a tag being fetched
 needs to overwrite existing one, failed to fetch other tags, which
 has been corrected.

 Expecting a (hopefully small and final) reroll.
 cf. <CAOLa=ZQ-O7V9qHbgeuQ78R1bHGDmGEM6fP5Kr9aC0AfvSF8MZA@mail.gmail.com>
 source: <20251121-fix-tags-not-fetching-v8-0-23b53a8a8334@gmail.com>


* lc/rebase-trailer (2025-11-05) 4 commits
 - rebase: support --trailer
 - trailer: append trailers in-process and drop the fork to `interpret-trailers`
 - trailer: move process_trailers to trailer.h
 - interpret-trailers: factor out buffer-based processing to process_trailers()

 Refactor code paths to run "interpret-trailers" from "git
 commit/tag" and use it in "git rebase".

 Expecting a reroll.
 cf. <19a8fe42354.3909481a3912041.7970296104893780556@linux.beauty>
 source: <20251105142944.73061-1-me@linux.beauty>


* jc/exclude-with-gitignore (2025-11-04) 1 commit
 - dir.c: do not be fooled by :(exclude) pathspec elements

 "git add ':(exclude)foo.o'" is clearly a request not to add 'foo.o',
 but the command complained about listing an ignored path foo.o on
 the command line, which has been corrected.

 Comments?
 source: <xmqqtsz9o3cn.fsf@gitster.g>


* bc/sha1-256-interop-02 (2025-11-17) 15 commits
 - object-file-convert: always make sure object ID algo is valid
 - rust: add a small wrapper around the hashfile code
 - rust: add a new binary object map format
 - rust: add functionality to hash an object
 - rust: add a build.rs script for tests
 - hash: expose hash context functions to Rust
 - write-or-die: add an fsync component for the object map
 - csum-file: define hashwrite's count as a uint32_t
 - rust: add additional helpers for ObjectID
 - hash: add a function to look up hash algo structs
 - rust: add a hash algorithm abstraction
 - rust: add a ObjectID struct
 - hash: use uint32_t for object_id algorithm
 - conversion: don't crash when no destination algo
 - repository: require Rust support for interoperability

 The code to maintain mapping between object names in multiple hash
 functions is being added, written in Rust.
 source: <20251117221621.2863243-1-sandals@crustytoothpaste.net>


* ar/run-command-hook (2025-12-04) 11 commits
 - receive-pack: convert receive hooks to hook API
 - receive-pack: convert update hooks to new API
 - hooks: allow callers to capture output
 - run-command: allow capturing of collated output
 - hook: allow overriding the ungroup option
 - reference-transaction: use hook API instead of run-command
 - transport: convert pre-push to hook API
 - hook: convert 'post-rewrite' hook in sequencer.c to hook API
 - hook: provide stdin via callback
 - run-command: add stdin callback for parallelization
 - run-command: add first helper for pp child states

 Use hook API to replace ad-hoc invocation of hook scripts with the
 run_command() API.

 Will merge to 'next'?
 source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>


* je/doc-reset (2025-10-17) 4 commits
 - doc: git-reset: clarify `git reset <pathspec>`
 - doc: git-reset: clarify `git reset [mode]`
 - doc: git-reset: clarify intro
 - doc: git-reset: reorder the forms

 Documentation updates.

 Expecting a reroll.
 cf. <8099e7ef-2673-407e-8cca-e6b566b99549@app.fastmail.com>
 source: <pull.1991.git.1760731558.gitgitgadget@gmail.com>


* ps/history (2025-12-03) 13 commits
 - builtin/history: implement "split" subcommand
 - cache-tree: allow writing in-memory index as tree
 - add-patch: allow disabling editing of hunks
 - add-patch: add support for in-memory index patching
 - add-patch: remove dependency on "add-interactive" subsystem
 - add-patch: split out `struct interactive_options`
 - add-patch: split out header from "add-interactive.h"
 - builtin/history: implement "reword" subcommand
 - builtin: add new "history" command
 - replay: stop using `the_repository`
 - replay: extract logic to pick commits
 - wt-status: provide function to expose status for trees
 - Merge branch 'pw/replay-exclude-gpgsig-fix' into ps/history
 (this branch is used by pw/replay-drop-empty.)

 "git history" history rewriting UI.

 Ready?
 source: <20251203-b4-pks-history-builtin-v7-0-9e9f849bfd0e@pks.im>


* ms/doc-worktree-side-by-side (2025-10-10) 2 commits
 - doc: git-worktree: Add side by side branch checkout example
 - doc: git-worktree: Link to examples

 Document "git worktree add" and use of out-of-tree worktrees with
 examples.

 Expecting a reroll.
 cf. <CAPig+cSNesf0UwS4=Bxe-Qn+G9y3YYPyOK+7y3q8QJk+o7jaVg@mail.gmail.com>
 source: <a203b35538847f3c9358a5ae26fb4ebea5734cfc.1759420102.git.msuchanek@suse.de>


* ar/submodule-gitdir-tweak (2025-11-19) 7 commits
 - meson/Makefile: allow setting submodule encoding at build time
 - submodule: use hashed name for gitdir
 - submodule: fix case-folding gitdir filesystem colisions
 - submodule: add extension to encode gitdir paths
 - submodule: always validate gitdirs inside submodule_name_to_gitdir
 - builtin/credential-store: move is_rfc3986_unreserved to url.[ch]
 - submodule--helper: use submodule_name_to_gitdir in add_submodule

 Avoid local submodule repository directory paths overlapping with
 each other by encoding submodule names before using them as path
 components.

 Expecting a reroll.
 source: <20251119211030.2008441-1-adrian.ratiu@collabora.com>

--------------------------------------------------
[Discarded]

* wm/complete-git-short-opts (2025-11-26) 1 commit
 - completion: complete "git -<TAB>" with short options

 The command line completion script (in contrib/) learned to
 complete "git -<TAB>" to give single-letter options like "-C".

 Will discard.  We do not complete single-letter options themselves.
 cf. <xmqqo6onjfwl.fsf@gitster.g>
 source: <pull.2100.v2.git.git.1764174391776.gitgitgadget@gmail.com>

Re: What's cooking in git.git (Dec 2025, #03)

[Adrian Ratiu]

On Fri, 12 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
> * ar/run-command-hook (2025-12-04) 11 commits
>  - receive-pack: convert receive hooks to hook API
>  - receive-pack: convert update hooks to new API
>  - hooks: allow callers to capture output
>  - run-command: allow capturing of collated output
>  - hook: allow overriding the ungroup option
>  - reference-transaction: use hook API instead of run-command
>  - transport: convert pre-push to hook API
>  - hook: convert 'post-rewrite' hook in sequencer.c to hook API
>  - hook: provide stdin via callback
>  - run-command: add stdin callback for parallelization
>  - run-command: add first helper for pp child states
>
>  Use hook API to replace ad-hoc invocation of hook scripts with the
>  run_command() API.
>
>  Will merge to 'next'?
>  source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>

I think this can be merged to next, since the latest iteration has been
sitting for a few weeks with no more feedback and all tests are green.

Landing this will also unblock my next series to add parallel/config
hooks on top of this one.

Many thanks,
Adrian

Re: What's cooking in git.git (Dec 2025, #03)

[Junio C Hamano]

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

> On Fri, 12 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
>> * ar/run-command-hook (2025-12-04) 11 commits
>> ...
>>  Use hook API to replace ad-hoc invocation of hook scripts with the
>>  run_command() API.
>>
>>  Will merge to 'next'?
>>  source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>
>
> I think this can be merged to next, since the latest iteration has been
> sitting for a few weeks with no more feedback and all tests are green.

"tests being green" tells us that with the current coverage we
didn't see any regression but not more than that.  Especially, it
does not say anything about the quality of new code (and test) and
if it is in good shape to build on top.  

It also is very hard to tell from "no more feedback" if there is no
room for further improvements, or people are simply disinterested in
the topic and are not tempted to spend their brain cycles to help
improve the topic.

If there is no more comments, I'll try to see if I can block some
time to read the topic over myself with a pair of fresh eyes before
deciding.

Thanks for pinging.

Re: What's cooking in git.git (Dec 2025, #03)

[Patrick Steinhardt]

On Tue, Dec 16, 2025 at 10:59:56AM +0900, Junio C Hamano wrote:
> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
> 
> > On Fri, 12 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
> >> * ar/run-command-hook (2025-12-04) 11 commits
> >> ...
> >>  Use hook API to replace ad-hoc invocation of hook scripts with the
> >>  run_command() API.
> >>
> >>  Will merge to 'next'?
> >>  source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>
> >
> > I think this can be merged to next, since the latest iteration has been
> > sitting for a few weeks with no more feedback and all tests are green.
> 
> "tests being green" tells us that with the current coverage we
> didn't see any regression but not more than that.  Especially, it
> does not say anything about the quality of new code (and test) and
> if it is in good shape to build on top.  
> 
> It also is very hard to tell from "no more feedback" if there is no
> room for further improvements, or people are simply disinterested in
> the topic and are not tempted to spend their brain cycles to help
> improve the topic.
> 
> If there is no more comments, I'll try to see if I can block some
> time to read the topic over myself with a pair of fresh eyes before
> deciding.

Thanks for the ping, I've now did another pass through v4 of this patch
series. It looked mostly good except for one question I had. Depending
on the answer I think this should be ready to go.

Thanks!

Patrick

Re: What's cooking in git.git (Dec 2025, #03)

[Adrian Ratiu]

On Tue, 16 Dec 2025, Patrick Steinhardt <ps@pks.im> wrote:
> On Tue, Dec 16, 2025 at 10:59:56AM +0900, Junio C Hamano wrote:
>> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>> 
>> > On Fri, 12 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
>> >> * ar/run-command-hook (2025-12-04) 11 commits
>> >> ...
>> >>  Use hook API to replace ad-hoc invocation of hook scripts with the
>> >>  run_command() API.
>> >>
>> >>  Will merge to 'next'?
>> >>  source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>
>> >
>> > I think this can be merged to next, since the latest iteration has been
>> > sitting for a few weeks with no more feedback and all tests are green.
>> 
>> "tests being green" tells us that with the current coverage we
>> didn't see any regression but not more than that.  Especially, it
>> does not say anything about the quality of new code (and test) and
>> if it is in good shape to build on top.  
>> 
>> It also is very hard to tell from "no more feedback" if there is no
>> room for further improvements, or people are simply disinterested in
>> the topic and are not tempted to spend their brain cycles to help
>> improve the topic.
>> 
>> If there is no more comments, I'll try to see if I can block some
>> time to read the topic over myself with a pair of fresh eyes before
>> deciding.
>
> Thanks for the ping, I've now did another pass through v4 of this patch
> series. It looked mostly good except for one question I had. Depending
> on the answer I think this should be ready to go.

I'll give Junio some more days in case he wants to take a look again at
the series, then send one last re-roll fixing your nits/question and
also addressing Junio's feedback, if there is any.

Thanks!

Re: What's cooking in git.git (Dec 2025, #03)

[Emily Shaffer]

On Tue, Dec 16, 2025 at 2:42 AM Adrian Ratiu <adrian.ratiu@collabora.com> wrote:
>
> On Tue, 16 Dec 2025, Patrick Steinhardt <ps@pks.im> wrote:
> > On Tue, Dec 16, 2025 at 10:59:56AM +0900, Junio C Hamano wrote:
> >> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
> >>
> >> > On Fri, 12 Dec 2025, Junio C Hamano <gitster@pobox.com> wrote:
> >> >> * ar/run-command-hook (2025-12-04) 11 commits
> >> >> ...
> >> >>  Use hook API to replace ad-hoc invocation of hook scripts with the
> >> >>  run_command() API.
> >> >>
> >> >>  Will merge to 'next'?
> >> >>  source: <20251204141535.1986263-1-adrian.ratiu@collabora.com>
> >> >
> >> > I think this can be merged to next, since the latest iteration has been
> >> > sitting for a few weeks with no more feedback and all tests are green.
> >>
> >> "tests being green" tells us that with the current coverage we
> >> didn't see any regression but not more than that.  Especially, it
> >> does not say anything about the quality of new code (and test) and
> >> if it is in good shape to build on top.
> >>
> >> It also is very hard to tell from "no more feedback" if there is no
> >> room for further improvements, or people are simply disinterested in
> >> the topic and are not tempted to spend their brain cycles to help
> >> improve the topic.
> >>
> >> If there is no more comments, I'll try to see if I can block some
> >> time to read the topic over myself with a pair of fresh eyes before
> >> deciding.
> >
> > Thanks for the ping, I've now did another pass through v4 of this patch
> > series. It looked mostly good except for one question I had. Depending
> > on the answer I think this should be ready to go.
>
> I'll give Junio some more days in case he wants to take a look again at
> the series, then send one last re-roll fixing your nits/question and
> also addressing Junio's feedback, if there is any.

FWIW, I also expect Josh Steadmon to find time to take a look at this
series soon, but he has been busy with personal side of things for the
last few days. It's not that there's disinterest from our side, more
that there is a lot going on :)

 - Emily

>
> Thanks!

Re: What's cooking in git.git (Dec 2025, #03)

[Junio C Hamano]

Emily Shaffer <nasamuffin@google.com> writes:

> FWIW, I also expect Josh Steadmon to find time to take a look at this
> series soon, but he has been busy with personal side of things for the
> last few days. It's not that there's disinterest from our side, more
> that there is a lot going on :)

Thanks, and thanks Josh for further inputs.

Re: What's cooking in git.git (Dec 2025, #03)

[René Scharfe]

On 12/12/25 11:26 AM, Junio C Hamano wrote:
> * rs/macos-iconv-workaround (2025-12-09) 1 commit
>  - config.mak.uname: use iconv from Homebrew on macOS
> 
>  Workaround that "iconv" shipped as part of macOS, which is broken
>  handling ISO-2022 encoded strings.
> 
>  Will merge to 'next'?
>  source: <16efc726-34be-44f5-aa92-4e82b663ab3d@web.de>
Not, yet, please.  Just sent v2 which adds NO_HOMEBREW.

René

Re: What's cooking in git.git (Dec 2025, #03)

[Aaron Plattner]

On 12/12/25 2:26 AM, Junio C Hamano wrote:
> * ap/packfile-promisor-object-optim (2025-12-08) 2 commits
>   - packfile: skip hash checks in add_promisor_object()
>   - object: apply skip_hash and discard_tree optimizations to unknown blobs too
> 
>   The code path that enumerates promisor objects have been optimized
>   to skip pointlessly parsing blob objects.
> 
>   Comments?
>   source: <20251209014900.402637-1-aplattner@nvidia.com>
Jeff King said v2 of the patch looked good to him but recommended 
splitting it into two changes. I don't know if he wanted to review v3 or 
if he was okay with it based on his comments on v2. The only differences 
in v3 are the commit count and descriptions.

-- Aaron

Re: What's cooking in git.git (Dec 2025, #03)

[Junio C Hamano]

Aaron Plattner <aplattner@nvidia.com> writes:

> On 12/12/25 2:26 AM, Junio C Hamano wrote:
>> * ap/packfile-promisor-object-optim (2025-12-08) 2 commits
>>   - packfile: skip hash checks in add_promisor_object()
>>   - object: apply skip_hash and discard_tree optimizations to unknown blobs too
>> 
>>   The code path that enumerates promisor objects have been optimized
>>   to skip pointlessly parsing blob objects.
>> 
>>   Comments?
>>   source: <20251209014900.402637-1-aplattner@nvidia.com>
> Jeff King said v2 of the patch looked good to him but recommended 
> splitting it into two changes. I don't know if he wanted to review v3 or 
> if he was okay with it based on his comments on v2. The only differences 
> in v3 are the commit count and descriptions.

v3 did not have links back to previous iterations, and

https://lore.kernel.org/git/?q=s%3A%22improve+--exclude-promisor-objects+performance%22

does not even show v1 or v2 (understandable if the topic was
retitled, which is not a bad thing, but makes it harder to find the
previous discussions in a case like this).  So as far as whoever
wrote the entry in the "What's cooking" report you quoted was
concerned, what [*] showed

 * https://lore.kernel.org/git/20251209014900.402637-1-aplattner@nvidia.com/

was everything known about the topic, which unfortunately had no
supporting comments.

Is this

  https://lore.kernel.org/git/20251206002014.2066644-1-aplattner@nvidia.com/

which I found in

  https://lore.kernel.org/git/?q=f%3Aaplattner%40nvidia.com

the v2 discussion?  We are lucky that you are not as prolific as
some contributors, for whom an author-name search would have found
way too many messages ;-)

I can see that the end result of applying the v3 patches match what
was in v2, and v3 separates along the lines Peff suggested in his

  https://lore.kernel.org/git/20251208202812.GC216526@coredump.intra.peff.net/

so that's an endorsement enough, I guess ;-).

Let's mark the topic for 'next', then.  Thanks.

Re: What's cooking in git.git (Dec 2025, #03)

[Aaron Plattner]

On 12/16/25 9:02 PM, Junio C Hamano wrote:
> Aaron Plattner <aplattner@nvidia.com> writes:
> 
>> On 12/12/25 2:26 AM, Junio C Hamano wrote:
>>> * ap/packfile-promisor-object-optim (2025-12-08) 2 commits
>>>    - packfile: skip hash checks in add_promisor_object()
>>>    - object: apply skip_hash and discard_tree optimizations to unknown blobs too
>>>
>>>    The code path that enumerates promisor objects have been optimized
>>>    to skip pointlessly parsing blob objects.
>>>
>>>    Comments?
>>>    source: <20251209014900.402637-1-aplattner@nvidia.com>
>> Jeff King said v2 of the patch looked good to him but recommended
>> splitting it into two changes. I don't know if he wanted to review v3 or
>> if he was okay with it based on his comments on v2. The only differences
>> in v3 are the commit count and descriptions.
> 
> v3 did not have links back to previous iterations, and
> 
> https://lore.kernel.org/git/?q=s%3A%22improve+--exclude-promisor-objects+performance%22
> 
> does not even show v1 or v2 (understandable if the topic was
> retitled, which is not a bad thing, but makes it harder to find the
> previous discussions in a case like this).  So as far as whoever
> wrote the entry in the "What's cooking" report you quoted was
> concerned, what [*] showed
> 
>   * https://lore.kernel.org/git/20251209014900.402637-1-aplattner@nvidia.com/
> 
> was everything known about the topic, which unfortunately had no
> supporting comments.
> 
> Is this
> 
>    https://lore.kernel.org/git/20251206002014.2066644-1-aplattner@nvidia.com/
> 
> which I found in
> 
>    https://lore.kernel.org/git/?q=f%3Aaplattner%40nvidia.com
> 
> the v2 discussion?  We are lucky that you are not as prolific as
> some contributors, for whom an author-name search would have found
> way too many messages ;-)

I'm sorry, I should have looked more closely at the format of other 
v(n>1) messages on the list and noticed the links to the previous 
discussions. In retrospect, that should have been an obvious requirement...

For completeness, here's all of the discussion:

v1: 
https://lore.kernel.org/git/4bd18399-26b3-44cd-93a7-8d2d32bef709@nvidia.com/T/
v2: 
https://lore.kernel.org/git/20251206002014.2066644-1-aplattner@nvidia.com/T/
v3: 
https://lore.kernel.org/git/20251209014900.402637-1-aplattner@nvidia.com/T/

> I can see that the end result of applying the v3 patches match what
> was in v2, and v3 separates along the lines Peff suggested in his
> 
>    https://lore.kernel.org/git/20251208202812.GC216526@coredump.intra.peff.net/
> 
> so that's an endorsement enough, I guess ;-).
> 
> Let's mark the topic for 'next', then.  Thanks.

Thank you, I appreciate it!

-- Aaron

Re: What's cooking in git.git (Dec 2025, #03)

[Jeff King]

On Tue, Dec 16, 2025 at 09:20:05PM -0800, Aaron Plattner wrote:

> > I can see that the end result of applying the v3 patches match what
> > was in v2, and v3 separates along the lines Peff suggested in his
> > 
> >    https://lore.kernel.org/git/20251208202812.GC216526@coredump.intra.peff.net/
> > 
> > so that's an endorsement enough, I guess ;-).
> > 
> > Let's mark the topic for 'next', then.  Thanks.
> 
> Thank you, I appreciate it!

Sorry, I'm a bit behind on reading the list. Yes, v3 looks great to me.
Thanks for working on it, and for pinging for review!

-Peff

Re: What's cooking in git.git (Dec 2025, #03)

[Junio C Hamano]

Aaron Plattner <aplattner@nvidia.com> writes:

>> Let's mark the topic for 'next', then.  Thanks.
>
> Thank you, I appreciate it!

;-)

Re: What's cooking in git.git (Dec 2025, #03)

[Aaron Plattner]

On 12/12/25 2:26 AM, Junio C Hamano wrote:
> * ps/object-read-stream (2025-11-23) 20 commits
>    (merged to 'next' on 2025-12-09 at c8d645f8ea)
>   + streaming: drop redundant type and size pointers
>   + streaming: move into object database subsystem
>   + streaming: refactor interface to be object-database-centric
>   + streaming: move logic to read packed objects streams into backend
>   + streaming: move logic to read loose objects streams into backend
>   + streaming: make the `odb_read_stream` definition public
>   + streaming: get rid of `the_repository`
>   + streaming: rely on object sources to create object stream
>   + packfile: introduce function to read object info from a store

This commit seems to have caused a slowdown in commit performance. On my 
production codebase (the one from [1] with the ridiculously enormous 
promisor pack), a simple commit that touches 9 files (out of 232,259 
total in the tree) goes from 0.38 seconds to 1508 seconds.

I'm pretty sure the problem is when do_oid_object_info_extended() 
substitutes the blank oi here:

	if (!oi)
		oi = &blank_oi;

and then packfile_store_read_object_info() compares it to its own local 
blank oi:

	static struct object_info blank_oi = OBJECT_INFO_INIT;

         [...]

	/*
	 * We know that the caller doesn't actually need the
	 * information below, so return early.
	 */
	if (oi == &blank_oi)
		return 0;

Here it's comparing the oi parameter to the address of a local static 
variable instead of the one from the caller, and the condition is always 
false.

-- Aaron

>   + streaming: move zlib stream into backends
>   + streaming: create structure for filtered object streams
>   + streaming: create structure for packed object streams
>   + streaming: create structure for loose object streams
>   + streaming: create structure for in-core object streams
>   + streaming: allocate stream inside the backend-specific logic
>   + streaming: explicitly pass packfile info when streaming a packed object
>   + streaming: propagate final object type via the stream
>   + streaming: drop the `open()` callback function
>   + streaming: rename `git_istream` into `odb_read_stream`
>   + Merge branch 'ps/object-source-loose' into ps/object-read-stream
> 
>   The "git_istream" abstraction has been revamped to make it easier
>   to interface with pluggable object database design.
> 
>   Will merge to 'master'.
>   source: <20251123-b4-pks-odb-read-stream-v3-0-1a129182822b@pks.im>
[1] 
https://lore.kernel.org/git/20251209014900.402637-1-aplattner@nvidia.com/T/

Re: What's cooking in git.git (Dec 2025, #03)

[Junio C Hamano]

Aaron Plattner <aplattner@nvidia.com> writes:

> I'm pretty sure the problem is when do_oid_object_info_extended() 
> substitutes the blank oi here:
>
> 	if (!oi)
> 		oi = &blank_oi;
>
> and then packfile_store_read_object_info() compares it to its own local 
> blank oi:
>
> 	static struct object_info blank_oi = OBJECT_INFO_INIT;

Ahh, that's an unusual mistake.

The following was done on top of 'seen', but would it help?  We
shouldn't have to use the stand-in "blank" thing to begin with.

Besides, explicitly handling the NULL case would reduce the
potential chance of errors that somebody accidentally writes into
blank_oi, making its contents dirty.




 object-file.c |  8 ++++----
 odb.c         | 29 +++++++++++++----------------
 packfile.c    |  3 +--
 3 files changed, 18 insertions(+), 22 deletions(-)

diff --git c/object-file.c w/object-file.c
index af1c3f972d..6280e42f34 100644
--- c/object-file.c
+++ w/object-file.c
@@ -426,7 +426,7 @@ int odb_source_loose_read_object_info(struct odb_source *source,
 	unsigned long size_scratch;
 	enum object_type type_scratch;
 
-	if (oi->delta_base_oid)
+	if (oi && oi->delta_base_oid)
 		oidclr(oi->delta_base_oid, source->odb->repo->hash_algo);
 
 	/*
@@ -437,13 +437,13 @@ int odb_source_loose_read_object_info(struct odb_source *source,
 	 * return value implicitly indicates whether the
 	 * object even exists.
 	 */
-	if (!oi->typep && !oi->sizep && !oi->contentp) {
+	if (!oi || (!oi->typep && !oi->sizep && !oi->contentp)) {
 		struct stat st;
-		if (!oi->disk_sizep && (flags & OBJECT_INFO_QUICK))
+		if ((!oi || !oi->disk_sizep) && (flags & OBJECT_INFO_QUICK))
 			return quick_has_loose(source->loose, oid) ? 0 : -1;
 		if (stat_loose_object(source->loose, oid, &st, &path) < 0)
 			return -1;
-		if (oi->disk_sizep)
+		if (oi && oi->disk_sizep)
 			*oi->disk_sizep = st.st_size;
 		return 0;
 	}
diff --git c/odb.c w/odb.c
index 01a9d2e70f..8278ef39a0 100644
--- c/odb.c
+++ w/odb.c
@@ -680,34 +680,31 @@ static int do_oid_object_info_extended(struct object_database *odb,
 				       const struct object_id *oid,
 				       struct object_info *oi, unsigned flags)
 {
-	static struct object_info blank_oi = OBJECT_INFO_INIT;
 	const struct cached_object *co;
 	const struct object_id *real = oid;
 	int already_retried = 0;
 
-
 	if (flags & OBJECT_INFO_LOOKUP_REPLACE)
 		real = lookup_replace_object(odb->repo, oid);
 
 	if (is_null_oid(real))
 		return -1;
 
-	if (!oi)
-		oi = &blank_oi;
-
 	co = find_cached_object(odb, real);
 	if (co) {
-		if (oi->typep)
-			*(oi->typep) = co->type;
-		if (oi->sizep)
-			*(oi->sizep) = co->size;
-		if (oi->disk_sizep)
-			*(oi->disk_sizep) = 0;
-		if (oi->delta_base_oid)
-			oidclr(oi->delta_base_oid, odb->repo->hash_algo);
-		if (oi->contentp)
-			*oi->contentp = xmemdupz(co->buf, co->size);
-		oi->whence = OI_CACHED;
+		if (oi) {
+			if (oi->typep)
+				*(oi->typep) = co->type;
+			if (oi->sizep)
+				*(oi->sizep) = co->size;
+			if (oi->disk_sizep)
+				*(oi->disk_sizep) = 0;
+			if (oi->delta_base_oid)
+				oidclr(oi->delta_base_oid, odb->repo->hash_algo);
+			if (oi->contentp)
+				*oi->contentp = xmemdupz(co->buf, co->size);
+			oi->whence = OI_CACHED;
+		}
 		return 0;
 	}
 
diff --git c/packfile.c w/packfile.c
index ce6716fbea..3ffd6c7240 100644
--- c/packfile.c
+++ w/packfile.c
@@ -2132,7 +2132,6 @@ int packfile_store_read_object_info(struct packfile_store *store,
 				    struct object_info *oi,
 				    unsigned flags UNUSED)
 {
-	static struct object_info blank_oi = OBJECT_INFO_INIT;
 	struct pack_entry e;
 	int rtype;
 
@@ -2143,7 +2142,7 @@ int packfile_store_read_object_info(struct packfile_store *store,
 	 * We know that the caller doesn't actually need the
 	 * information below, so return early.
 	 */
-	if (oi == &blank_oi)
+	if (!oi)
 		return 0;
 
 	rtype = packed_object_info(store->source->odb->repo, e.p, e.offset, oi);

Re: What's cooking in git.git (Dec 2025, #03)

[Patrick Steinhardt]

On Thu, Dec 18, 2025 at 11:57:30AM +0900, Junio C Hamano wrote:
> Aaron Plattner <aplattner@nvidia.com> writes:
> 
> > I'm pretty sure the problem is when do_oid_object_info_extended() 
> > substitutes the blank oi here:
> >
> > 	if (!oi)
> > 		oi = &blank_oi;
> >
> > and then packfile_store_read_object_info() compares it to its own local 
> > blank oi:
> >
> > 	static struct object_info blank_oi = OBJECT_INFO_INIT;
> 
> Ahh, that's an unusual mistake.
> 
> The following was done on top of 'seen', but would it help?  We
> shouldn't have to use the stand-in "blank" thing to begin with.
> 
> Besides, explicitly handling the NULL case would reduce the
> potential chance of errors that somebody accidentally writes into
> blank_oi, making its contents dirty.

Yeah, indeed I've already found that regression myself and got it
cooking in a local patch series. I was holding off from sending that
series because there was a minor conflict with an in-flight one. But
I'll take this opportunity and send it out now.

Thanks for the report and your initial triaging, Junio!

Patrick