Re: Git dumb HTTP protocol should work without update-server-info

Patrick Steinhardt [off-list ref] writes:

On Sun, Sep 07, 2025 at 03:07:11PM +0000, brian m. carlson wrote:

quoted

I will also note that the dumb HTTP protocol doesn't work with reftable
and there was some suggestion of removing it for Git 3.0.  It certainly
will not work out of the box with Git 3.0, since the default is
reftable.

Yes, indeed. In theory though reftables could also be the solution to
the underlying issue: the client can be tought to read the "tables.list"
file and then fetch all tables listed therein. The result would be fully
consistent, unless any of the tables gets garbage collected. The client
would notice and abort the operation, after which it could restart the
operation.

In that case there would be no need for git-update-server-info(1)
anymore. The "tables.list" file sits in a well-known location,
identifies all other tables we have to download, and there are no
atomicity issues anymore.

Does tables.list list what pack files there are in the repository?  
I somehow doubt it.

The dumb HTTP transport was meant to be able to operate with a truly
dumb HTTP server, that does not even have to support WebDAV at all,
so there needs some tables at known name that lists _all_ the files
the cloners are expected to be able to download from.  We still need
the output from update-server-info [*] to tell what packs are there
even if tables.list is stored at the known path.


[Footnote]

* ... or its equivalent generated offline and uploaded manually to
  the repository, which was what I did before I got an account at
  kernel.org.  There was a small web space at local ISP provided for
  its subscribers, so my "push" was to ftp upload the loose objects,
  packs, refs, and the info/refs + objects/info/packs files there X-<.