Git supports read-only, static HTTP cloning using nothing but "GET" requests on a bare Git repository. IOW, you don't need a CGI program or special request proc

Git supports read-only, static HTTP cloning using nothing but "GET" requests on a bare Git repository. IOW, you don't need a CGI program or special request processor to serve a Git repository over HTTP. All you need to do is 1) make the bare Git repository visible under your web server's document root the same as-if you were serving .gif or .js files, and 2) maintain a special index after every commit using `git --bare update-server-info`, which I invoke from a post-receive hook.[1] Because of this, you don't even need a CGI program for a web UI. Theoretically, it could all be done from client-side JavaScript. I've been wanting to write a PoC, but it's deep in my side-project backlog. Why bother? Because a read-only, static Git mirror is more secure--there's no server software (other than a basic web server) that can be exploited. And nothing is always easier to maintain than something. You still need SSH (or a git:// daemon) for write access, unless the entire environment is just for read-only cloning. But SSH access is presumably something already setup and used by the core contributors. (Probably shell access, too, but SSH logins can always be forced to invoke git.) IMO, static, read-only HTTP cloning is a killer feature of Git which AFAIK cannot be matched by CVS, Subversion, Mercurial, or Fossil, at least not out-of-the-box. [1] From a hook on the read-write, master repository outside the web server sandbox.