What is it?
I have created a script (POSIX sh compatible) that allows running git- http-backend via inetd or similar service (it makes it like git-http- backend had a --inet option just like git-daemon does).

This allows the Git smart HTTP protocol to be served without needing to run a standard web server (assuming inetd, xinetd, launchd or similar is already available).

It is available at [1] with a GPL license.

I have several machines/virtual machines that need to be able to fetch from a central Git repository without authentication (several of them are test platforms and are therefore not trusted and typing a password on every fetch is a non-starter as some of the fetches are automated). I also don't want to have to run a web server just to serve Git fetches.

Of course you say, "why not use git daemon for that?" Well, I was (in --inetd mode), but it has a serious problem and until recently I didn't know the cause.

Talking to a git-daemon server works great for my FreeBSD, Darwin, cygwin, msysgit platforms, but it's terrible for my Linux platforms.

On the Linux platforms every git fetch would hang for at least 15 seconds before starting the fetch. I just wrote that off as some odd configuration issue I was going to have to live with (although it only happened with Git and not web browsing or curl fetches). It's killer though when fetching a project with lots of submodules as each one has the delay.

Recently though, I discovered the cause. While I don't actually run Debian itself, all my Linux platforms are Debian offspring (Ubuntu, Raspbian, Linux Mint, etc.). The problem is in the Debian git package [2] specifically the "0010-transport-optionally-honor-DNS-SRV- records.diff" patch located in the Debian diffs file [3].

The 0010 patch makes "git://host/..." fetches first try to fetch a git SRV record from DNS. This patch has a compile time option to enable it, but once baked in it cannot be turned off at runtime and the binary packages for my distributions all have it turned on and baked in. And none of these distributions have a visible "WARNING: Git has patches that may cause it to behave oddly, violate RFC standards and/ or experience unexpected delays."

It so happens that my internal network is setup using mDNS [4] (on Linux/FreeBSD by installing Avahi and nss-mdns packages).

When I then try to fetch using a "git://host/..." URL where "host" is an mDNS host name, the 0010 patch causes git to attempt to lookup a DNS SRV record on the non-mDNS regular DNS service (a violation of RFC 6762 [4] section 22) and this is what has to time out before the real fetch can start.

Since the patch does not try to lookup an SRV record for "http:// host/..." URLs, switching from git: to http: for fetches eliminates the problem. However, git-http-backend does not have any of the -- daemon or --inetd related options that git-daemon does. Hence the git_inetd_server.sh script [1] that provides the equivalent of a -- inetd option for git-http-backend.

I have since discovered that the 0010 patch behavior can be bypassed by explicitly including a port number in the git: URLs. So instead of "git://example.local/repo.git" using "git://example.local:9418/ repo.git" avoids the delaying SRV lookup. This is highly unintuitive since omitting the default port for a scheme should not change its behavior (according to RFC 3986 [5] section 3.2.3 the port should be omitted by producers and normalizers if it's the same as the scheme's default port). In any case, unless git_inetd_server.sh can be run on the default http port (80), the resulting http: URLs are no more convenient than the git: URLs with an explicit port.

Nonetheless, others may find this script helpful as it allows the Git smart (and non-smart) HTTP protocol to be served without needing to run a standard web server so I decided to share it.


[1] https://github.com/mackyle/git_inetd_server
[2] https://packages.debian.org/wheezy/git
[4] RFC 6762 http://tools.ietf.org/html/rfc6762
[5] RFC 3986 http://tools.ietf.org/html/rfc3986

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to