Issue with git clone via http/https and alternates

2 messages, 2 authors, 2021-12-10 · open the first message on its own page

Issue with git clone via http/https and alternates

From: Ralf Baechle <hidden>
Date: 2021-12-09 19:59:19

I'm hosting a number of largish repositories which being very similar
are using git's alternates feature to save disk and memory.  Cloning via
git:// or ssh for users with accounts on the server works as expected but
cloning via http or https results fails as follows:

$ git clone http://git.linux-mips.org/pub/scm/linux-mti.git
Cloning into 'linux-mti'...
warning: alternate disabled by http.followRedirects: http://git.linux-mips.org/pub/scm/ralf/linux.git/
error: Unable to find e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0 under http://git.linux-mips.org/pub/scm/linux-mti.git
Fetching objects: 11, done.
Cannot obtain needed object e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0
while processing commit 9e2bf7cf7d9003c0f06736be5218ed79234f254c.
error: fetch failed.

Adding -c http.followRedirects=true will make the clone succeed. Question,
shouldn't the default of http.followRedirects=initial already suffice?

Anyway, what I'm looking for is something I can do serverside so users
cloning the repository are not bothered with this http.followRedirects
business.  Is there anything I can do?

Thanks,

  Ralf

Re: Issue with git clone via http/https and alternates

From: Jeff King <hidden>
Date: 2021-12-10 04:08:19

On Thu, Dec 09, 2021 at 08:59:14PM +0100, Ralf Baechle wrote:
I'm hosting a number of largish repositories which being very similar
are using git's alternates feature to save disk and memory.  Cloning via
git:// or ssh for users with accounts on the server works as expected but
cloning via http or https results fails as follows:

$ git clone http://git.linux-mips.org/pub/scm/linux-mti.git
Cloning into 'linux-mti'...
warning: alternate disabled by http.followRedirects: http://git.linux-mips.org/pub/scm/ralf/linux.git/
error: Unable to find e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0 under http://git.linux-mips.org/pub/scm/linux-mti.git
Fetching objects: 11, done.
Cannot obtain needed object e4add961d4aaeb19f607f6d7bea8d59e1bd39ff0
while processing commit 9e2bf7cf7d9003c0f06736be5218ed79234f254c.
error: fetch failed.

Adding -c http.followRedirects=true will make the clone succeed. Question,
shouldn't the default of http.followRedirects=initial already suffice?
There are security implications to allowing more redirects. See
cb4d2d35c4 (http: treat http-alternates like redirects, 2016-12-06).
That commit message does mention that we could be more lenient for
same-server redirects here, but AFAIK this is the first time anybody
cared enough to even bring it up the list.

That said...
Anyway, what I'm looking for is something I can do serverside so users
cloning the repository are not bothered with this http.followRedirects
business.  Is there anything I can do?
Turn on smart-http support for your server. The dumb-http protocol is
rather inefficient, and is what requires the client to even know about
your server-side alternates in the first place. And personally, I have a
lot less trust in it in general, compared to smart-http. There have been
tons of fixes and improvements in the smart-http code in the past 10
years, and I don't think anybody is really paying much attention to
dumb-http.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help