+To completely disable repository access for an existing user, return their shell
+to /bin/bash:
+
+ sudo chsh -s /bin/bash <existinguser>
+
+or, instead, ensure their access permissions to repositories is set to none for
+both subversion and git repositories.
+
+= Access paths for client side access
+
+Users interact with subversion and git repositories using what we somewhat
+incorrectly call access paths. In both cases, the access path is relative to
+the respective repository type root, as defined in /etc/repo_shell.conf. In
+other words, the user does not need to know where the repository is stored. In
+the case of git, a repository can be under a subdirectory. A couple of
+examples:
+
+ svn checkout svn+ssh://server/my_repository/trunk my_repository
+ git clone server:my_repository.git
+ git clone server:mirrors/tinyos/tinyos-main.git
+
+= Repository access for gitweb
+
+The following steps can allow gitweb to filter the available repositories
+according to the authenticated user and the contents of the .gitacl file.
+
+- The web server must require authorization and a valid user for URI's starting
+ with /gitweb. Recommend using a PAM module, since repo_shell also works of
+ the system user credentials.
+- The web server needs to pass the REMOTE_USER environment variable to
+ gitweb.cgi.
+- The contents of the file gitweb.conf.addon must be added to the server's
+ gitweb.conf file, usually found in /etc.
+
+The contents of gitweb.conf.addon essentially define an $export_auth_hook that
+uses repo_shell's test mode to validate read access for the web server
+authenticated user for each repository gitweb can see.
+
+= Repository access for other applications
+
+Local system applications, such as web based viewers, may gain read-only access
+to repositories by adding the user which runs such a tool to the repository
+owner's group. However, such an access method bypasses access control
+functionality and all repositories will be viewable by the application.
+
+A better solution, requiring some scripting work, would be to have the other
+application use output from the repo_shell -c command to determine access.
+
+ repo_shell -c <username> <reponame>
+
+This command returns one of three results. An empty return string means no
+access, an "r" means read-only, and "rw" means read-write access.
+
+= Allow other users to create repositories
+
+With the following configuration, other users could be configured to run the
+`gitcreate` command using sudo.
+
+First, run `visudo` as root to edit the `/etc/sudoers` file. These entries
+should appear before less specific rules. The Runas_Alias REPOUSER should be
+set to the value of the `owner` variable defined in `/etc/repo_shell.conf`.
+
+ # Allow select users to run gitcreate
+ User_Alias REPOCREATORS = user1, user2, user3
+ Runas_Alias REPOUSER = repo
+ REPOCREATORS ALL = (REPOUSER) NOPASSWD: /usr/local/bin/gitcreate
+
+Now any users listed in the User_Alias REPOCREATORS can run the gitcreate
+command. The command would be invoked as follows:
+
+ ssh <repohost>
+ sudo -u repo gitcreate path/to/newrepo.git
+
+Note that as of right now, repo_shell cannot be used to run this command in a
+single ssh invocation, such as:
+
+ ssh <repohost> sudo gitcreate path/to/newrepo.git
+
+This is because repo_shell does not implement a full tty needed by sudo if it
+must ask the user for a password to authenticate the action.
+
+= References and links
+
+repo_shell owes great thanks to work shared by two other projects:
+
+- The GIT stupid content tracker - http://git-scm.org
+ Some useful information was gleaned from git's git-shell program.
+ GIT is licensed under the GPLv2.
+
+- The inih .ini parser library - http://code.google.com/p/inih/
+ This is a great little library for handling simple configuration files.
+ inih is licensed under a modified BSD license, available in inih/LICENSE.txt.