On Mon, May 10, 2021 at 02:40:16PM +0100, Stefan Hajnoczi wrote: > On Mon, May 10, 2021 at 11:31 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > > For the https:// URIs should we setup a HTTP redirect ? > > > > When git clones via https it fetches some specific paths which > > I believe we have rules for in httpd conf: > > > > ScriptAliasMatch "^/git/(.*\.git/(HEAD|info/refs))$" \ > > /usr/libexec/git-core/git-http-backend/$1 > > ScriptAliasMatch "^/git/(.*\.git/git-(upload|receive)-pack)$" \ > > /usr/libexec/git-core/git-http-backend/$1 > > > > If we set those URI path matches to send a HTTP 307 redirect > > to gitlab, that would essentially kill off our git traffic on > > qemu.org, while still allowing the qemu.org gitweb UI to > > work normally. The downside is that people won't notice to > > update their clone URIs. Still feels like an easy win and > > we can easily remove the redirect if we use code 307. > > I remember there were concerns about warning messages that > git-clone(1) prints when an HTTP redirect is encountered? If everyone > is okay I can turn the git-http-backend(1) aliases into HTTP 307 > redirects to GitLab.
I presume that'll be the case with git fetch/pull too, and anything else which talks to the server. None the less, if git prints a warning message when getting a redirect, I'd say that is probably a desirable feature, as it'll make it more likely that people will fix their URIs to directly point at gitlab. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
