Re: [PATCH v3 0/6] odb: make packfile generation pluggable

On Thu, Aug 20, 2026 at 12:55 AM Patrick Steinhardt <[email protected]> wrote:
>
> Hi,
>
> this patch series makes packfile generation pluggable.
>
> Note that this series only makes those parts pluggable that are required
> for the transport layer. The other parts that relate to packfile
> generation as required by our repository maintenance is kept as-is, as
> there is a bunch of options there that are way too specific to the
> "files" backend to be portable. This should ultimately not be much of a
> problem though, as maintenance itself is already pluggable in the first
> place.
>
> It's a bit of a shame though for git-pack-objects(1), which still isn't
> usable with alternate backends. I tried several times to find good
> solutions for making it fully pluggable, but due to the backend-specific
> options it's an utter mess. I want to eventually address this though:
> same as with git-refs(1), I want to introduce git-objects(1) to care
> about all things ODB. And as part of that command we can also introduce
> a command that generates packfiles in a generic fashion, without all the
> cruft that git-pack-objects(1) has. This is part of a future patch
> series though.

So, big picture, today there are three callers that spawn "git
pack-objects --revs --stdout ..." by hand to produce a pack for
transfer: upload-pack, send-pack, and bundle.  Each hand-rolls a
child_process, feeds a rev list on stdin, and drains the pack from the
child's stdout.  This series hoists that shared machinery into a new
object-database interface, decoupling the transport use of packs from
the storage use.  I like it.

> Changes in v3:
>   - Fix a use-after-scope bug on abnormal exit when child processes are
>     cleaned up via `mark_child_for_cleanup()`, as noticed by Elijah.
>   - Link to v2: https://patch.msgid.link/[email protected]

Thanks, the fix in 1/6 addresses what I raised on v2.

I read through the series -- I did have an alternative suggestion for
5/6 (which I posted on v2 5/6 since there was already a thread there),
but otherwise I didn't spot anything beyond what other reviewers
already raised.