Patrick Steinhardt <ps@xxxxxx> writes:
> The reason why I added this project is that I found it to be interesting
> as a thought experiment. The reason why we have "info/refs" is to help
> out clients of the dumb HTTP transport to figure out actual refs in the
> repository because they typically live in many separate files. But what
> I realized is that we don't actually need it with the reftable format
> anymore because we basically already have a definitive list of all files
> that a client needs to download to acquire all refs: "tables.list".
Yes, YES, YES!!!
> So theoretically speaking we can implement support for dumb HTTP with
> reftables by having the client download "tables.list" and then fetch all
> the "*.ref" files listed in it. Whether that is sensible may be a
> different question.
It is not even theoretical---I think it is the RIGHT way to do the
dumb HTTP walker if we had reftable from the beginning. Having a
file at a known location where we can start "walking" from is
a very powerful thing [*1*].
If we do not have to change the server side at all, which I think
what you are saying, that removes the major part of the problem I
was having with this proposal. I do not even have to worry about
speaking with the first-world bias and hurting folks with needs that
are only served by the dumb HTTP walker, either.
By the way, about two years ago, we have talked about making the
first step to deprecate dumb HTTP walker [*2*], but given that
nothing concrete materialized, we are ready to move further, yet.
[Footnote]
*1* With the filesystem backed refs, because there was no standard
and widely supported way to ask a dumb HTTP server "what are the
files and directories under this hierarchy?" and that was here
the ugly "info/refs" hack came from.
*2* https://lore.kernel.org/git/f8639116d2d384a6d285c75830c52d8a8230ae6b.1647243509.git.ps@xxxxxx/
