Re: [PATCH v3 2/6] upload-pack: generate packfiles via the object database
Karthik Nayak <[email protected]>
| Newsgroups | org.kernel.vger.git |
|---|---|
| Message-ID | <CAOLa=ZQLEg-Ufo0QUEpf2sxuJ=G=8zvT1+deDg7JzxNQTQivLg@mail.gmail.com> |
Patrick Steinhardt <[email protected]> writes: > On Thu, Aug 20, 2026 at 06:24:09AM -0400, Karthik Nayak wrote: >> Patrick Steinhardt <[email protected]> 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. > Okay that makes sense. Thanks! >> > 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
signature.asc
(application/pgp-signature, 690 B)
-----BEGIN PGP SIGNATURE----- iQHKBAEBCgA0FiEEV85Mf2N1cQ/LZcYGPtWfJI5GjH8FAmqHbW8WHGthcnRoaWsu MTg4QGdtYWlsLmNvbQAKCRA+1Z8kjkaMf4z8C/9/fAtnRk4OvadRQmLsYZWwVGqJ 9PkJF1PbzTCX9SZVDQ815nbUIndGNRsVCtCU1K6xVdoDTlP+W7UOP7PrlSrGu0h2 HL/AsR91hJe91S6r+kB8tALq4DQ8YIDcRScs/kvJwTkDOK5ALdDHp05FZtZP8m7X jkMfol6CDr5H/sdoPYizWcJZdvJ1rhqvA/xIg907wB/M14BfTtXnGYNnR1YU4ECf dLSrbduQirg6zKMkTet/UtCA0kHDahW8Wr6tI9gNeh6Eqt3FGzv5tpkyE2chWL/n Vhq6cwh64sca3hGDh3HEIKwFy8z2xeUyASfC7a0ssn86kqmLuCo0cTM3TxmQtNyk a9fUx6OZgZndIfwuHNO7muRu90pmF72bEgEnrB/Bf0D8uaYBcNxHJqr33/rGWmxB jdmCMweKx5MhhElTrF74JQ+K6CV3n7T88/L8ffjD87hDZslT3SGWRZuQ9X0uZ+DS +c+h2MMXjfvzi7EADSE3703owxe8uPXLYKrwDvA= =Pzie -----END PGP SIGNATURE-----