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

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Sun, Sep 07, 2025 at 03:07:11PM +0000, brian m. carlson wrote:
>> 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-<.