On Thu, Aug 20, 2026 at 06:24:09AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > When serving a fetch, git-upload-pack(1) spawns git-pack-objects(1)
> > directly to generate the packfile that gets sent to the client. This
> > hard-codes the assumption that the object database is able to serve
> > packfiles via git-pack-objects(1), which is specific to the "files"
> > backend.
> >
>
> Naive question, the previous patch says that only the primary odb source
> will be used to generate the packfile and we added the implementation
> for the files backend.
>
> Does this mean that this will only work if the files backend is the
> primary backend?
The primary backend is the one that will generate packs in the first
place. For now, the only primary backend that we ever have is the
"files" backend. But if we ever add a different backend then that would
of course implement its own implementation for generating packs.
So at the status quo: yes, but with the added infrastructure it's now
pluggable and can be implemented by other backends, too.
> > diff --git a/upload-pack.c b/upload-pack.c
> > index a52856d869..75a857eaa8 100644
> > --- a/upload-pack.c
> > +++ b/upload-pack.c
[snip]
> > + if (odb_generate_pack(the_repository->objects, &generator, &opts))
> > + die("git upload-pack: unable to fork git-pack-objects");
>
> Nit: should we still talk about 'forking' here? As far as upload-pack is
> considered, it handed over the task to the odb, 'forking' is an internal
> implementation detail.
Fair, we should probably just say "unable to pack objects" here.
Patrick