Re: What's cooking in git.git (Oct 2025, #02; Mon, 6)
- From
Elijah Newren <newren@gmail.com>
- Date
- Oct 8, 2025, 04:10 UTC
- Message-ID
- <CABPp-BEPYFua9XvNBbn3kzEksyqrrTKfViMtG3=-=YSEU3Jdrg@mail.gmail.com>
- In-Reply-To
- <xmqqqzvfmwcx.fsf@gitster.g>
On Mon, Oct 6, 2025 at 4:41 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 60 quoted lines
> > -------------------------------------------------- > [Cooking] > > * tb/incremental-midx-part-3.1 (2025-09-29) 51 commits > - SQUASH??? play well with other topics by preemptively including "repository.h" > - builtin/repack.c: clean up unused `#include`s > - repack: move `write_cruft_pack()` out of the builtin > - repack: move `write_filtered_pack()` out of the builtin > - repack: move `pack_kept_objects` to `struct pack_objects_args` > - repack: move `finish_pack_objects_cmd()` out of the builtin > - builtin/repack.c: pass `write_pack_opts` to `finish_pack_objects_cmd()` > - repack: extract `write_pack_opts_is_local()` > - repack: move `find_pack_prefix()` out of the builtin > - builtin/repack.c: use `write_pack_opts` within `write_cruft_pack()` > - builtin/repack.c: introduce `struct write_pack_opts` > - repack: 'write_midx_included_packs' API from the builtin > - builtin/repack.c: inline packs within `write_midx_included_packs()` > - builtin/repack.c: pass `repack_write_midx_opts` to `midx_included_packs` > - builtin/repack.c: inline `remove_redundant_bitmaps()` > - builtin/repack.c: reorder `remove_redundant_bitmaps()` > - repack: keep track of MIDX pack names using existing_packs > - builtin/repack.c: use a string_list for 'midx_pack_names' > - builtin/repack.c: extract opts struct for 'write_midx_included_packs()' > - builtin/repack.c: remove ref snapshotting from builtin > - repack: remove pack_geometry API from the builtin > - builtin/repack.c: pass 'packdir' to `pack_geometry_remove_redundant()` > - builtin/repack.c: pass 'pack_kept_objects' to `pack_geometry_init()` > - builtin/repack.c: rename various pack_geometry functions > - builtin/repack.c: remove "repack_promisor_objects()" from the builtin > - builtin/repack.c: pass "packtmp" to `repack_promisor_objects()` > - repack: remove 'generated_pack' API from the builtin > - builtin/repack.c: provide pack locations to `generated_pack_install()` > - builtin/repack.c: pass "packtmp" to `generated_pack_populate()` > - builtin/repack.c: factor our "generated_pack_install" > - builtin/repack.c: rename "struct generated_pack_data" > - repack: remove 'existing_packs' API from the builtin > - builtin/repack.c: avoid unnecessary numeric casts in existing_packs > - builtin/repack.c: pass "packdir" when removing packs > - repack: remove 'remove_redundant_pack' from the builtin > - builtin/repack.c: rename many 'struct existing_packs' functions > - repack: remove 'prepare_pack_objects' from the builtin > - repack: move 'delta_base_offset' to 'struct pack_objects_args' > - builtin/repack.c: pass both pack_objects args to repack_config > - repack: introduce new compilation unit > - builtin/repack.c: avoid using `hash_to_hex()` in pack geometry > - builtin/repack.c: avoid "the_hash_algo" in `finish_pack_objects_cmd()` > - builtin/repack: avoid "the_hash_algo" in `repack_promisor_objects()` > - builtin/repack.c: avoid "the_hash_algo" in `write_oid()` > - builtin/repack.c: avoid "the_hash_algo" when deleting packs > - builtin/repack.c: avoid "the_repository" when repacking promisor objects > - builtin/repack.c: avoid "the_repository" when removing packs > - builtin/repack.c: avoid "the_repository" when taking a ref snapshot > - builtin/repack.c: avoid "the_repository" in existing packs API > - builtin/repack.c: avoid "the_repository" in `cmd_repack()` > - Merge branch 'ps/packfile-store' into tb/incremental-midx-part-3.1 > (this branch uses ps/packfile-store.) > > Comments? > source: <cover.1759097191.git.me@ttaylorr.com>
I'll try to take a look...
Show 8 quoted lines
> * cc/doc-submitting-patches-with-ai (2025-10-01) 1 commit > - SubmittingPatches: add section about AI > > AI guidelines. > > Perhaps we should adopt what QEMU uses for simplicity? > cf. <aOBMHqLxNd86vgjH@fruit.crustytoothpaste.net> > source: <20251001140310.527097-1-christian.couder@gmail.com>
I preferred the version Christian sent out over the QEMU adaptation...
Show 10 quoted lines
> * rj/doc-technical-fixes (2025-10-02) 3 commits > - doc: commit-graph.adoc: fix up some formatting > - doc: sparse-checkout.adoc: fix asciidoc warnings > - doc: remembering-renames.adoc: fix asciidoc warnings > (this branch uses rj/doc-missing-technical-docs.) > > Documenation mark-up fixes. > > Comments? > source: <20251002221233.541844-1-ramsay@ramsayjones.plus.com>
Documenation -> Documentation
Ramsay commented that he had a small fixup to send after waiting for more feedback (https://lore.kernel.org/git/436fb507-6764-46f4-abb1-34c82e27b808@ramsayjones.plus.com/), so maybe mark as waiting for a re-roll?
The series looked fine to me, I just feel bad for causing so much work for him. Are the things in Documentation/technical/ meant to be pretty-formatted and distributed anywhere? I assumed the audience was fellow git developers and the original .txt file (that someone else renamed to .adoc) was the preferred viewing format.
Show 7 quoted lines
> * kh/doc-patch-id-markup-fix (2025-09-29) 1 commit > - doc: patch-id: fix accidental literal blocks > > Documenaotin mark-up fix. > > Will merge to 'next'? > source: <v2-e5ad12cc3b3.1759178715.git.code@khaugsbakk.name>
I think Documentation is determined to be misspelled in your release notes, in various exciting ways. :-)
Show 10 quoted lines
> * sa/replay-atomic-ref-updates (2025-09-26) 1 commit > - replay: make atomic ref updates the default behavior > (this branch is used by ps/history.) > > "git replay" (experimental) learned to perform ref updates itself > in a transaction by default, instead of emitting where each refs > should point at and leaving the actual update to another command. > > Comments? > source: <20250926230838.35870-2-siddharthasthana31@gmail.com>
Maybe mark as expecting a reroll? Christian, Phillip, and I all left several comments, and Siddharth responded to each of us saying he'd incorporate the feedback into the next round.
Show 15 quoted lines
> * bc/sha1-256-interop-01 (2025-10-02) 9 commits > - t1010: use BROKEN_OBJECTS prerequisite > - t: allow specifying compatibility hash > - fsck: consider gpgsig headers expected in tags > - rev-parse: allow printing compatibility hash > - docs: add documentation for loose objects > - docs: improve ambiguous areas of pack format documentation > - docs: reflect actual double signature for tags > - docs: update offset order for pack index v3 > - docs: update pack index v3 format > > The beginning of SHA1-SHA256 interoperability work. > > Will merge to 'next'? > source: <20251002223855.1022847-1-sandals@crustytoothpaste.net>
brian said he was planning on sending a v3 (https://lore.kernel.org/git/aOA6z-kFCd78XtxX@fruit.crustytoothpaste.net/), so maybe not yet?
Show 19 quoted lines
> * en/xdiff-cleanup (2025-09-26) 12 commits > - xdiff: change type of xdfile_t.changed from char to bool > - xdiff: add macros DISCARD(0), KEEP(1), INVESTIGATE(2) in xprepare.c > - xdiff: rename rchg -> changed in xdfile_t > - xdiff: delete chastore from xdfile_t > - xdiff: delete fields ha, line, size in xdlclass_t in favor of an xrecord_t > - xdiff: delete redundant array xdfile_t.ha > - xdiff: delete struct diffdata_t > - xdiff: delete local variables that alias fields in xrecord_t > - xdiff: delete superfluous function xdl_get_rec() in xemit > - xdiff: delete unnecessary fields from xrecord_t and xdfile_t > - xdiff: delete local variables and initialize/free xdfile_t directly > - xdiff: delete static forward declarations in xprepare > > A lot of code clean-up of xdiff. > Split out of a larger topic. > > Will merge to 'next'? > source: <pull.2048.v6.git.git.1758926520.gitgitgadget@gmail.com>
I think so; I stopped an earlier almost merge down to next (https://lore.kernel.org/git/CABPp-BH-oaV+fJ4u50oofy54ycE5oKoYJ6O1XgEt_JfDSgXvxg@mail.gmail.com/)...and then seemingly sparked an awful lot of other reviews as well (or maybe people just were intrigued by something in the rerolls). Either way, the topic seems to have been quiet for a few weeks now, and I think the topic looks ready to merge down now.
Show 17 quoted lines
> * ds/sparse-checkout-clean (2025-09-12) 7 commits > (merged to 'next' on 2025-09-25 at 00b296f153) > + 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 > > "git sparse-checkout" subcommand learned a new "clean" action to > prune otherwise unused working-tree files that are outside the > areas of interest. > > On hold. > cf. <3537e220-44b6-4e37-a568-cef34a2fddfd@gmail.com> > source: <pull.1941.v3.git.1757673011.gitgitgadget@gmail.com>
I think it's almost ready, it just needs a few messages improved; I commented on a couple patches and the cover letter.