Re: What's cooking in git.git (Oct 2026, #10)

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 29, 2026, 12:37 UTC
Message-ID: <auM-JvB3IS8I5Yka@pks.im>
In-Reply-To: <xmqqo6cd5hnt.fsf@gitster.g>

On Wed, Oct 28, 2026 at 08:07:02PM -0700, Junio C Hamano wrote:

Show 10 quoted lines

> * pw/allow-compound-literals (2026-10-26) 1 commit
> * hk/test-t1467-refs-rename (2026-10-28) 1 commit
> * hn/ci-fail-on-missing-deps (2026-10-27) 2 commits
> * lb/reflog-expire-dry-run-fix (2026-10-23) 1 commit
> * oa/diffcore-rename-no-the-repository (2026-10-24) 1 commit
> * sm/prune-packed-libification (2026-10-27) 1 commit
> * ks/unit-tests-ignore-long-tests (2026-10-26) 2 commits
> * mh/init-show-abspath (2026-10-27) 1 commit
> * dk/stash-completion-updates (2026-10-23) 5 commits
> * je/doc-merge-conflicts (2026-10-26) 6 commits

All of these topics topics marked as "Will merge to next?" look good to me.

Show 11 quoted lines

> * oa/bundle-uri-drop-the-repository (2026-10-28) 1 commit
>  - bundle-uri: use the passed repository for refs and tracing
> 
>  Functions 'unbundle_from_file()' and 'fetch_bundle_uri()' have been
>  updated to use their passed-in repository context instead of relying
>  on the global 'the_repository'.
> 
>  Will merge to 'next'?
>  cf. <CAOLa=ZQK_ZjCj5G+rk2Cz+-hQ054uJW6Eq4NEofQLHx0jnnfWQ@mail.gmail.com>
>  cf. <xmqqcxstbx4v.fsf@gitster.g>
>  source: <20261028093455.76247-1-okhuomonajayi54@gmail.com>

The patch itself looks good, but I left a comment there that we can trivially get rid of the remaining two uses of `the_repository`, as well. And if so we could drop `USE_THE_REPOSITORY_VARIABLE` altogether.

Show 10 quoted lines

> * sp/t0001-avoid-pipe (2026-10-22) 1 commit
>  - t0001: avoid pipes in test scripts
> 
>  The test script 't0001-init' has been updated to avoid piping the
>  output of 'git version' directly into 'sed', ensuring command failures
>  are properly caught.
> 
>  Needs review.
>  cf. <xmqqbj8lhcng.fsf@gitster.g>
>  source: <pull.2260.v3.git.1792732388827.gitgitgadget@gmail.com>

Mostly there, but there's a formatting error in the commit message. You could fix that up manually, but seeing that this is in the context of Outreachy I think it's better to let the contributor fix this. Also because this issue was present in v2 already.

Show 10 quoted lines

> * sj/oss-fuzz-commit-graph-gitdir (2026-10-24) 1 commit
>  - oss-fuzz: set a gitdir in the commit-graph fuzzer
> 
>  The commit-graph fuzzer has been updated to supply a placeholder
>  '.gitdir' to the repository. This prevents early failures when
>  prepare_repo_settings() is called, allowing the fuzzer to proceed and
>  test optional chunks such as generation data and Bloom filters.
> 
>  Needs review.
>  source: <CAOJ8FdeyJp4ZOfp99DBSp4brWzngdqzrkSY36ByEh=4UPw28Mg@mail.gmail.com>

I had a look, looks good to me.

Show 20 quoted lines

> * ps/odb-object-storage-extension (2026-10-26) 7 commits
>  - builtin/submodule: propagate "--object-storage-format="
>  - builtin/clone: introduce "--object-storage-format="
>  - builtin/init: introduce handling of object storage format
>  - builtin: expose the object storage format
>  - setup: allow overriding object storage format via environment
>  - setup: introduce object storage extension
>  - loose: drop unused `repo_write_loose_object_map()`
>  - Merge branch 'ps/setup-enforce-repo-passed-to-create-repository-has-no-state' into ps/odb-object-storage-extension
>  - Merge branch 'ps/odb-files-alternates' into ps/odb-object-storage-extension
> 
>  The object storage format has been made configurable via the
>  'extensions.objectStorage' configuration variable, allowing users
>  to specify the storage backend and an optional payload, mirroring
>  the design of 'extensions.refStorage'.
> 
>  Expecting a reroll?
>  cf. <auHc9TeCfrCurKTM@pks.im>
>  cf. <CAOLa=ZRWktyBmeeiMbPqnX_OkizqPA2mmGrnTABW7Pkk7DcKpA@mail.gmail.com>
>  source: <20261027-b4-pks-odb-extension-v4-0-5d28ca0ea1dc@pks.im>

The only change I've got queued is this one:

2:  81f6d2b09e3 ! 2:  0f85938a5d2 setup: introduce object storage extension
    @@ Commit message
             allows you to configure a different location for the ".git/objects"
             directory.
     
    -    Making the location of the "files" backend configurable is not he most
    +    Making the location of the "files" backend configurable is not the most
         thrilling feature of this new extension. But it gives us a couple of
         advantages:

I can send out a new version to fix this, but maybe this is something you could fix up locally? Whatever works best for you.

Show 11 quoted lines

> * ps/gitlab-ci-whitespace-job-shallow-clone-fix (2026-10-16) 1 commit
>  - gitlab-ci: fix "check" jobs with large merge requests
> 
>  The GitLab CI configuration has been updated to disable shallow clones
>  for the 'check-whitespace' and 'check-style' jobs by setting
>  'GIT_DEPTH' to 0, preventing them from failing on large merge requests
>  that exceed the default shallow clone depth.
> 
>  Needs review.
>  cf. <CAOLa=ZTwyGnWFa4U=8UDzEUuyhQ7jT555FCh-CBp_wos9rJG9w@mail.gmail.com>
>  source: <20261016-pks-ci-optional-whitespace-job-v1-1-f5693fbae1a5@pks.im>

Karthik approved this, CI is happy and the fix is somewhat trivial. I'd hope that we can merge this soon-ish to fix our CI.

Show 13 quoted lines

> * kn/fetch-tag-backfill-batch-fix (2026-10-28) 3 commits
>  - t5510: cover upstream info update on fetch failure
>  - fetch: advertise fetched refs when backfilling tags
>  - transport: add `transport_options_release()`
> 
>  The tag backfilling negotiation in 'git fetch' has been updated to
>  explicitly include the in-flight fetched tips as 'haves', preventing
>  the server from resending objects when batched reference updates are
>  used.
> 
>  Will merge to 'next'?
>  cf. <auHfmzP3aXyonp3C@pks.im>
>  source: <20261028-799-shallow-fetch-with-tags-v5-0-7c43cc9ae810@gmail.com>

I expect another tiny reroll, but that should probably be the last one.

Show 10 quoted lines

> * ps/repo-ref-storage-format-fix (2026-10-05) 1 commit
>  - builtin/repo: rename "references.format" to "references.storageFormat"
> 
>  The output of 'git repo info' has been updated to use
>  'references.storageFormat' instead of 'references.format' for
>  consistency with recent ref-storage-format terminology updates.
> 
>  Needs review.
>  cf. <CAOLa=ZTNNY_XuixqZ96TK0zFfDpWvxSupxVGOnH1VGXK4KF_0w@mail.gmail.com>
>  source: <20261005-pks-repo-ref-storage-format-v1-1-819a181572a9@pks.im>

I've got two positive reviews, so maybe this is ready to go?

cf. <CAOLa=ZTNNY_XuixqZ96TK0zFfDpWvxSupxVGOnH1VGXK4KF_0w@mail.gmail.com> cf. <as61Dh7ui54gdzGV@denethor>

Show 16 quoted lines

> * mc/refs-rename-transaction (2026-10-08) 4 commits
>  . refs: remove backend-specific copy and rename callbacks
>  . refs: run copy and rename through ordinary transactions
>  . refs: support replacing reflogs in a transaction
>  . refs: distinguish internal transactions from logical updates
> 
>  Both reference rename and copy operations have been refactored to use
>  the generic reference transaction API, ensuring that hooks observe the
>  updates as unified logical operations rather than piece-meal internal
>  deletions and additions.
> 
>  Waiting for response.  Breaks 'seen' when merged.
>  cf. <asdsIjNEUOpaAnX5@pks.im>
>  cf. <ash-bs4-WmGuLyCl@pks.im>
>  cf. <asmFLjno-vuuN1ZS@fruit.crustytoothpaste.net>
>  source: <cover.1791452597.git.maciej.ciemborowicz@gmail.com>

I think this topic should be evicted for now. I don't think that the result is sensible, and it was way too AI-heavy without the author having a clear understanding of what they are doing.

Thanks!

Patrick