Git & redirections

Question

I've noticed that when a git (html) project page such as this:

https://github.com/fruux/sabre-dav

is cloned, in this manner:

git clone https://github.com/fruux/sabre-dav .

The actual resulting remote url, as listed with git remote -v is a url such as this:

origin  [email protected]:foo/sabre-dav.git

Presumably because I have push access.

So this made me wonder whether it's possible to redirect any given project url to a git repository. If I for instance own http://myosproject.example.org, is it possible to allow git clone http://myosproject.example.org and have it actually redirect somehow to a github project instead.

Answer 1

As long as the bare git (the .git folder) is in the web servers DocumentRoot, and you set up a specific post-update hook, it will work.

See this book chapter for more on this

To map your own domain name to a github URL , I think you just need to define an A record (if you know the IP address) or a CNAME record (if you only know the domain name) in your DNS

It may also be possible to configure a reverse proxy in your web server to pass the request for http://my.domain.com/project to http://github.com/project.

Answer 2

If I for instance own http://myosproject.example.org, is it possible to allow git clone http://myosproject.example.org and have it actually redirect somehow to a GitHub project instead

It could be possible in theory if the server knew somehow to redirect the url.
Git now (2.12, Q1 2017) treat http-alternates like redirects.

See commit cb4d2d3, commit 50d3413, commit fcaa6e6, commit 6628eb4, commit 986d7f4 (06 Dec 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 8a2882f, 19 Dec 2016)}

There is another way for a server to ask a git client to fetch arbitrary content: by having an http-alternates file (or a regular alternates file, which is used as a backup).

• unless http.followRedirects is set to "always", we will not follow remote redirects from http-alternates (or alternates) at all
• set CURLOPT_PROTOCOLS alongside CURLOPT_REDIR_PROTOCOLS restrict ourselves to a known-safe set and respect any user-provided whitelist.
• mention alternate object stores on stderr so that the user is aware another source of objects may be involved.

---

Git 2.13 improves those http redirects by updating the base URL only if there is no error

See commit 8e27391 (28 Feb 2017) by Jonathan Tan (jhowtan).
^{(Merged by Junio C Hamano -- gitster -- in commit d0f549f, 10 Mar 2017)}

http.c supports HTTP redirects of the form

 http://foo/info/refs?service=git-upload-pack
 -> http://anything
 -> http://bar/info/refs?service=git-upload-pack

That is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the intermediate steps can have any URL.
However, if one of the intermediate steps results in an HTTP exception, a confusing "unable to update url base from redirection" message is printed instead of a Curl error message with the HTTP exception code.

Teach http to check the HTTP status before attempting to check if only the "base" part of the URL differed.

---

But, as noted in xpt's question "git clone from redirect shorten url":

git clone should follow the redirect if httpfollowRedirects is not false.
Actually, the URLs that end with .git give 301, as well as old URLs of repos that have been renamed.

So 301 ("Moved permanently"), not 302 ("Found"), used for instance by git.io (even though git.io is deprecated, starting Apr. 29th, 2022).