|title: "Hosting Git repositories from your user account using Gitolite"|
|date: 2014-03-25 18:44|
How many times have you been in this situation: You recognize the need to use version control in your organization, or at least on your projects. Your organization does not. Your sysadmins are unresponsive to requests to support new things regardless the lack of any kind of VCS. Nonetheless, you refuse to not use VC on your projects.
Have you never been in that situation? Weird. You're lucky.
Gitolite is a utility for serving up repositories and controlling which users are able to read, write, force-update, delete, or create repositories. Useful when coordinating a project between different people or from different machines.
The normal install instructions for Gitolite require a special user account, and as we've established, your organization might be unreceptive to doing things. Here I'll show you how to (somewhat sanely) host Gitolite in your own user account without bothering admins.
You can leave the executable in a directory in your home directory.
git clone git://github.com/sitaramc/gitolite ~/gitolite
We'll be following "option 1" with reference to the Gitolite docs.
cd gitolite ./install
Gitolite authenticates using SSH.
To keep Gitolite usage segregated from your normal account usage, create a new keypair for Gitolite operations.
cd ~/.ssh dekkera:.ssh peter$ ssh-keygen -t rsa -f git_id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in git_id_rsa. Your public key has been saved in git_id_rsa.pub.
Store a copy of the
git_id_rsa.pub in the gitolite folder, as 'your_name.pub', and tell Gitolite to set up using that key. Reference Gitolite docs: setup and note we are using the "host alias" option.
cp git_id_rsa.pub ~/gitolite/your_name.pub cd ~/gitolite gitolite -setup -pk your_name.pub
It's worth stating what "setup" did.
First, it populated "~/repositories" with the default admin respository and the testing repository, and put you authorized key in the admin repository.
Then it checked out the admin repository to
Finally it added some lines to your
.ssh/authorized_keys file, like this:
# gitolite start command="/Users/peter/gitolite/src/gitolite-shell your_name",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza<rest of key>== your_name@your_host # gitolite end
These lines mean that an SSH connnection made using this public key will connect to the Gitolite shell. (When you add other users, this means you are giving permission for them to run Gitolite under your UID. This is why the usual practice is to have a separate UID for Gitolite, in case Gitolite has an exploit.)
Test it out now:
your_host:gitolite your_name$ ssh -x -i ~/.ssh/git_id_rsa your_name@your_host info hello yourname, this is your_name@your_host running gitolite3 v3.04-13-gcc9727c on git 1.9.1 R W gitolite-admin R W testing
Important things to note: gitolite is running under your uid (are you OK with that?), and there are two repos to start with that you can read and write to.
For convenience, you can also create a host alias, by adding these lines to
Host home User your_name Hostname your_host IdentityFile ~/.ssh/git_id_rsa
This means you can clone things from
home/repo rather than
your_name@your_host/repo (and if your gitolite host moves you can track it by updating your SSH config instead of updating all the remotes in your checked out repositories).
To facilitate interaction with Gitolite from your own account, make Git use this key. (Other users can use their keys ordinarily.) Make a script
cat > ~/bin/gitssh #!/bin/sh exec ssh -x -i ~/.ssh/git_id_rsa $@
Make it executable and this line to your
Administrate gitolite by cloning the admin respotitory.
dekkera:gitolite peter$ git clone your_name@your_host:gitolite-admin #can also "git clone home:gitolite-admin" with a host alias
(If this doesn't work, make sure you configured
gitssh and check the environment variable
GIT_SSH as discussed above.) Note that if you set up a host alias you can clone from
To add a user, go into
keydir and add their SSH public key as
To add repositories and control access permissions, edit
conf/gitolite.conf. and either add new lines for a new reporter.
See the docs. Go ahead and add these lines:
repo CREATOR/..* C = @all RW+D = CREATOR R = @all
This allows users to add and delete their own repositories stored under their own subdirectory.
R" allows reading, "
W" allows writing, and "
+" allows forced updating. "
C" allows creation and "
D" deletion of repositories.
Commit your changes and do a
git push and gitolite will receive the new setting.
your-host:gitolite-admin your_name$ git add -A your-host:gitolite-admin your_name$ git push origin master Everything up-to-date your-host:gitolite-admin your_name$ git commit -m 'adding self-created repo rule' [master c53a070] adding self-created repo rule 1 file changed, 6 insertions(+), 1 deletion(-) your-host:gitolite-admin your_name$ git push origin master Counting objects: 10, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 402 bytes | 0 bytes/s, done. Total 4 (delta 1), reused 0 (delta 0) To home:gitolite-admin 0b61e82..c53a070 master -> master
If you added a repo to
gitolite.conf you will see a message about initializing a new repo.
On another machine, make sure you have set up your host alias and a SSH keypair that gitolite recognizes, then do
git clone home:your_repo
Note that a user
other_name clones by running, effectively,
git clone your_name@your_host:repo, because the repos live in your account. So they are using SSH to connect to your account, and your
~/.ssh/config directs them to use
gitolite as a login shell.
Gitolite can communicate help and usage messages. Try the following:
ssh home help ssh home info ssh home desc -h
The lines we added with
CREATOR allows users to remotely create and delete repositories. See docs under wild repositories.
Try it out:
your-host:gitolite-admin your_name$ git clone home:your_name/new_repo Cloning into 'new_repo'... Initialized empty Git repository in /Users/your_name/repositories/your_name/new_repo.git/ warning: You appear to have cloned an empty repository. Checking connectivity... done.
You can also take an existing repository, set its remote to
home/your_name/new_repo, and push it on up.
Remotely deleting a repo requires enabling the delete command. To enable "D", uncomment the relevant line in
Then you can delete repositories where you have the "
your-host:~ your_name$ ssh home D unlock your_name/new_repo 'your_name/new_repo' is now unlocked your-host:~ your_name$ ssh home D rm your_name/new_repo 'your_name/new_repo' is now gone!
Gitolite can also control access to read and write on a per-branch level.
A useful configuration is to only allow non-forced updates for top-level branches, but allow contributors to do whatever they want (create, delete, force-update) with their own branches. This lets the repo owner control the top level, but contributors make their own branches and pull requests.
TODO show how this is done.
would like to automatically make a local mirror of my Github stuff; with triggers on pull and push