On Thu, Jan 13, 2022 at 02:23:54PM -0800, Markus Mayer wrote:
> On Thu, 13 Jan 2022 at 14:12, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 1/13/2022 1:53 PM, Alyssa Ross wrote:
> > > Hi,
> > >
> > > On Thu, Jan 13, 2022 at 01:44:23PM -0800, Florian Fainelli wrote:
> > >> Would you consider allowing git.musl-libc.org to serve the repositories over
> > >> https rather than git? For some obscure reasons some corporate environments
> > >> do block the git protocol whereas https goes through.
> > >
> > > You should be able to git clone https://git.musl-libc.org/cgit/musl.
> > > It is quite slow though -- since it looks like cgit is serving, this
> > > is presumably because cgit's built-in git serving feature only supports
> > > the legacy ("dumb") HTTP program, not the fast ("smart") one used by
> > > git http-backend, which would be a nice infrastructure improvement.
> >
> > I don't seem to be able to get cloning from cgit to work either and not
> > doing this in the corporate environment I vaguely mentioned but over my
> > home residential provider (Cox). git:// works.
>
> Interestingly, it worked for me. Kind of. It is *extremely* slow. It
> took about 15 minutes to clone the repo, which isn't big at all and
> should take no more than a minute to transfer (likely a lot less).
>
> Interestingly, the local clone created via cgit and https is 52 MB in
> size while a clone via the git:// protocol is only 20 MB. Something
> "interesting" seems to be happening when cloning via cgit. The repo
> does seem to be fully functional, though.

From what I remember (and take this with a grain of salt, because it's
been a long time since I looked into it), the "dumb" HTTP protocol works
by downloading pre-built packfiles from a static web server, whereas the
"smart" protocol can negotiate exactly the objects it needs with the
server.  This might explain the size difference.

I imagine if you git gc you'll end up with the same size as the git://
clone.