Setting up git-daemon allows you to export your repositories using the Git native protocol.

You must mark repositories as “OK to be exported” in some way. Typically this is done by creating the file git-daemon-export-ok in the top-level directory of the bare repository. This mechanism gives you fine-grained control over which repositories the daemon can export.

Instead of marking each repository individually, you can also run git-daemon with the --export-all option to publish all identifiable (by having both an objects and a refs subdirectory) repositories found in its list of directories. There are many git-daemon options that limit and configure which repositories will be exported.

One common way to set up the git-daemon daemon on a server is to enable it as an inetd service. This involves ensuring that your /etc/services has an entry for Git. The default port is 9418, though you may use any port you like. A typical entry might be:

git     9418/tcp      # Git Version Control System

Once you add that line to /etc/services, you must set up an entry in your /etc/inetd.conf to specify how the git-daemon should be invoked.

A typical entry might look like this:

# Place on one long line in /etc/inetd.conf

git stream tcp nowait nobody /usr/bin/git-daemon
        git-daemon --inetd --verbose --export-all
        --base-path=/pub/git

Using xinetd instead of inetd, place a similar configuration in the file /etc/xinetd.d/git-daemon:

# description: The git server offers access to git repositories
service git
{
    disable         = no
    type            = UNLISTED
    port            = 9418
    socket_type     = stream
    wait            = no
    user            = nobody
    server          = /usr/bin/git-daemon
    server_args     = --inetd --export-all --base-path=/pub/git
    log_on_failure  += USERID
}

You can make it look as if repositories are located on separate hosts, even though they’re just in separate directories on a single host, through a trick supported by git-daemon. The following example entry allows a server to provide multiple, virtually hosted Git daemons:

# Place on one long line in /etc/inetd.conf

git stream tcp nowait nobody /usr/bin/git-daemon
        git-daemon --inetd --verbose --export-all
        --interpolated-path=/pub/%H%D

In the command shown, git-daemon will fill in the %H with a fully qualified host name and %D with the repository’s directory path. Because %H can be a logical host name, different sets of repositories can be offered by one physical server.

Typically, an additional level of directory structure, such as /software, or /scm, is used to organize the advertised repositories. If you combine the --interpolated-path=/pub/%H%D with a /software repository directory path, the bare repositories to be published will be physically present on the server in directories such as:

/pub/git.example.com/software/
/pub/www.example.org/software/

You would then advertise the availability of your repositories at URLs such as:

git://git.example.com/software/repository.git
git://www.example.org/software/repository.git

Here the %H is replaced by the host git.example.com or www.example.org and the %D is replaced by full repository names, such as /software/repository.git.

The important point of this example is that it shows how a single git-daemon can be used to maintain and publish multiple, separate collections of Git repositories that are physically hosted on one server but presented as logically separate hosts. Those repositories available from one host might be different than those offered by a different host.

Sometimes, an easier way to publish repositories with anonymous read access is to simply make them available through an HTTP daemon. If you also set up gitweb, visitors can load a URL into their web browsers, see an index listing of your repository, and negotiate using familiar clicks and the browser Back button. Visitors needn’t be running Git in order to download files.

You will need to make one configuration adjustment to your bare Git repository before it can be properly served by an HTTP daemon: enable the hooks/post-update option as follows:

$ cd /path/to/bare/repo.git
$ mv hooks/post-update.sample hooks/post-update

Verify that the post-update script is executable, or use chmod 755 on it just to be sure. Finally, copy that bare Git repository into a directory served by your HTTP daemon. You can now advertise that your project is available using a URL such as:

http://www.example.org/software/repository.git

... not found: did you run git update-server-info on the server?

Perhaps git-update-server-info needs to be run there?

Although using a web server and browser is certainly convenient, think carefully about how much traffic you plan to handle on your server. Development projects can become large, and HTTP is less efficient than the native Git protocol.

You can provide both HTTP and Git daemon access, but it might take some adjusting and coordination between your Git daemon and your HTTP daemon. Specifically, it may require a mapping with the --interpolated-path option to git-daemon and an Alias option to Apache to provide seamless integration of the two views of the same data. Further details lie beyond the scope of this book.