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  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
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
 specifically the "0010-transport-optionally-honor-DNS-SRV-
records.diff" patch located in the Debian diffs file .
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  (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  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  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  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.
 RFC 6762 http://tools.ietf.org/html/rfc6762
 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