Re: What's cooking in git.git (Sep 2026, #01)

From: Elijah Newren <newren@gmail.com>
Date: Sep 4, 2026, 06:03 UTC
Message-ID: <CABPp-BE+_YhTpOODe1OP7LWdEj9MKV71OCVSd+exWKSoh+1+2A@mail.gmail.com>
In-Reply-To: <xmqqjyp3f7mr.fsf@gitster.g>

On Wed, Sep 2, 2026 at 6:27 PM Junio C Hamano <gitster@pobox.com> wrote:

[...]

Show 14 quoted lines

> * jk/rev-info-argv-to-free (2026-08-31) 2 commits
>  - revision: simplify mark_argv_for_free() callers
>  - revision: hang on to "freed" argv elements
>
>  The memory ownership of argv elements passed to the revision
>  machinery has been made more robust by keeping logically "freed"
>  elements alive until the rev_info struct is released, preventing
>  use-after-free bugs when options store references to them.
>
>  Will merge to 'next'?
>  cf. <apaSDqIEyc82Q_zE@pks.im>
>  cf. <apayIuf9kXQcQPvS@pks.im>
>  cf. <xmqq8q5ksvd8.fsf@gitster.g>
>  source: <20260901062815.GC1075462@coredump.intra.peff.net>

I think it's good to merge down.

Show 12 quoted lines

> * tc/replay-linearize (2026-08-31) 3 commits
>  - replay: offer an option to linearize the commit topology
>  - replay: resolve the replay base outside pick_regular_commit()
>  - replay: add helper to put entry into replayed_commits
>
>  The 'git replay' command has been taught the '--linearize' option to
>  drop merge commits and linearize the replayed history, mimicking 'git
>  rebase --no-rebase-merges'.
>
>  Will merge to 'next'?
>  cf. <CABPp-BF1=DZAxX5Now4pCKPi8=cpXo506z=8QVu2vYCSiKdqMA@mail.gmail.com>
>  source: <20260831-toon-git-replay-drop-merges-v9-0-61c4232c6f36@iotcl.com>

Yes, I think so.

Show 16 quoted lines

> * en/midx-missing-pack-fallback (2026-08-29) 4 commits
>  - packfile: recover when a multi-pack-index names a removed pack
>  - mktree: do not use OBJECT_INFO_QUICK when checking objects
>  - mktree: plug per-tree leak in --batch mode
>  - replay: fail gracefully when a merge input is unreadable
>  - Merge branch 'ps/odb-generic-corrupt-objects' into en/midx-missing-pack-fallback
>
>  The object lookup machinery has been taught to gracefully recover
>  when a multi-pack-index points to an owning pack that was removed
>  during a concurrent geometric repack, and 'git replay' has been
>  fixed to not segfault when reading such missing objects.
>
>  Will merge to 'next'?
>  cf. <20260831231005.GA973618@coredump.intra.peff.net>
>  cf. <374bffe1-47ff-4cb6-9d69-f4b7da7292da@gmail.com>
>  source: <pull.2207.v3.git.1787986831.gitgitgadget@gmail.com>

I believe so; it was acked by Peff, Patrick, and Stolee.

Stolee and I did add some extra discussion, but not about any changes to make, but rather clarifications about why the bug occurred frequently enough to affect production, and more detailed measures of the cost of the fallback to fix the bug.