Publishing Git repositories on a shared server

So you are the happy admin or user of a shared Linux server. You know that Git is very cool, and you want to install what's necessary on the shared server to host user repositories there. You're like me: you've read some Git documentation, but you just haven't found some sort of executive summary comprehensively listing how to do that. I hope this place will help!

Normally, any server on which users may login and have a personal web space, and core git binaries are installed, is sufficient for publishing git repositories, without any server admin task involved; however, what's proposed here results in a more formal repositories handling on the shared server, allowing a global view of all hosted repositories and unified management, and more cool git repository URLs using the native git protocol.

One time installation on the shared server
Create a new repository for a user
Basic usage for a user

One time installation on the shared server

Usually, even if upstream git is distributed as a single package, distros split git between git-core (the git utilities), gitweb (the web frontend, which needs Apache), and more. We need at least the two first ones. For Mandriva:
```
$ urpmi git-core gitweb
```
For other distros:
Gitweb is then available as http://<shared-server-hostname>/cgi-bin/gitweb.cgi (at that moment, 403 Forbidden - No projects found is shown though).
Create the base projet directory. This is the root directory where the git repositories will live. A safe choice is to use the default directory.
```
$ mkdir /pub/git
```
Most gitweb default configuration is fine, except you have to specify the URL list where the repositories will be available from; typically you specify the git://... URL from where the public will be able to anonymously clone repositories, and the ssh://... URL from where the users will be able to clone and push into their repositories. In /etc/gitweb.conf:
```
our @git_base_url_list = qw(git://<shared-server-hostname> ssh://<shared-server-hostname>/pub/git);
```

Offer anonymous access to git repositories, through git-daemon listening on port 9418. Usually it's done with xinetd, and if your distro doesn't offer a configuration file, here is one:

$ cat > /etc/xinetd.d/git-daemon <<EOF
# 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
}
EOF
$ service xinetd restart

If you wanted to have the base project directory elsewhere from default /pub/git, you'd have to set the location as $projectroot in /etc/gitweb.conf and amend @git_base_url_list, and as --base-path to git-daemon in the xinetd configuration.

Create a new repository for a user

A user tells an admin he'd like to have a new repository created for him.

We suppose the data for the repositories will live in the user directories, using symlinks from the base project directory, so that repository data live within user quotas. In the following examples, you may wish to rather have files in the base project directory if no user quota is enforced/wanted.

Have the user create his git repository. User may choose among several scenarios, typical examples are:

Empty repository (a dummy commit is needed for cloning the repository)

  # mkdir ~/gitrepos/<name>    (directory name doesn't matter, but the wanted name
                                for the repository makes sense)
  # cd ~/gitrepos/<name>
  # git init
  # touch foo
  # git add foo
  # git commit -m 'just an initial commit'

Import an existing tree (with no VCS history) into the repository

  # mkdir ~/gitrepos/<name>
  # cd ~/gitrepos/<name>
  # git init
  # tar xvf <archive>
  # git add .
  # git commit -m 'initial import'

Import a CVS repository
```
  # cd <cvs-repo-checkout-dir>
  # git-cvsimport -C ~/gitrepos/<name>
```
(it will even properly "merge" history of renamed files!)

Import an SVN repository

  # git-svn clone http://<svn-url> ~/gitrepos/<name>
  # rm -rf ~/gitrepos/<name>/.git/svn

Move his git repository directory to the base project directory. Ask the user the wanted name of his repository and use it below.
```
$ ln -s /home/johndoe/gitrepos/<name>/.git /pub/git/<name>
```
User should put a description for his repository as ~/gitrepos/<name>/.git/description, so that the gitweb project list is beautiful.
~/gitrepos/<name>/* should now be deleted (so that only the bare repository is kept), to avoid using an out of sync working tree there. User will clone his repository into somewhere else and work from there.

Basic usage for a user

This is really provided "as-is". Use it as a first-time demo or a very limited handbook. There are plenty of better usage docs on the web.

User can perform pull and push on his repository.

# cd ~/dev
# git clone ssh://<shared-server-hostname>/pub/git/<name>
# cd <name>
    hack...
# git add ..   (if new files were added)
# git diff
# git commit
    hack more...
# git commit
# git push   (push commits into master repository on shared server)

Contributors/viewers/lurkers can view the repository and perform local changes.

# cd /tmp
# git clone git://<shared-server-hostname>/pub/git/<name>
# cd <name>
    hack...
# git add ..   (if new files were added)
# git diff
# git commit
    hack more...
# git commit
# git pull   (synchronize with master repository on shared server)
# git diff origin   (view all the local changes to master repository)
# git format-patch origin   (generate patches for email submission)

User reviews and selectively apply patches, and pushes into master repository afterwards.

# git am -i <patchfile>
# git push

Guillaume Cottenceau
Last modification: Tue Jun 10 10:06:26 2008