Git use is managed by gitolite-admin. This would in fact be an actual Git project on a remote host that is cloned (checked out) and modified. This page is to show you how this works, but the surprise is that you risk over-thinking this process if you miss that you administer Git by using a project in Git.
You must have Git set up on your development host. This is not covered here.
Examine this snapshot of the gitolite-admin project (at one point in its existence):
gitolite-admin/ |-- conf | `-- gitolite.conf `-- keydir |-- [email protected] |-- [email protected] |-- [email protected] |-- [email protected] |-- [email protected] `-- [email protected]
You get this project for your own use on your own development host by performing the following action, for which you must already have rights as a Git user:
$ git clone git@swan-of-tuonela:gitolite-admin
There are two principal aspects to managing this project. These are:
Each group member submits a public RSA key created on his development host. For one example of how to do this, see here. He submits this key to the person administrating Git on the server.
The public key is added (new or in replacement of an existing one) to the path gitolite-admin/keydir. As suggested above, the name should be the server username followed by at-sign and then "main.pub". Git requires that the key name end at very least in ".pub". Then, the following commands are issued—just as they would be for the addition of any new file in Git:
$ git add [email protected] $ git commit [email protected] $ git push
(Note: Jenkins uses tomcat6; hence, that user here for which a public key is needed. For more on this, see A Brief Exposé on Jenkins.)
Below is an illustration of the gitolite administration configuration file where you'll see listed the name of those allowed to administrate Git. This list is different than the implicit list that is the list of public keys in this subdirectory. The intersection of both sets indicates who can administrate; all others are merely permitted access to projects in the repository. For example, the imaginary user we just added here in this discussion (user with RSA public key [email protected]) does not figure in the list of admins in the configuration file below.
File gitolite-admin/conf/gitolite.conf appeared thus (at one point in the existence of this project):
@admins = russ levi kyle albert jay camron
@others = tom ravi jenkins
@acme_repo = rest-server rest-test-client
repo gitolite-admin
RW+ = @admins
repo @acme_repo
RW+ = @admins
R = @others
At this point, this file granted administrative privileges to all team members, Albert, Camron, Jay, Kyle, Levi and Russ. It also specified three projects:
Once a project is added to the configuration file, it can be cloned by anyone with rights. However, the first time it's cloned, you'll see this:
$ git clone git@swan-of-tuonela:rest-server Initialized empty Git repository in /home/user/projects/rest-server/.git/ warning: You appear to have cloned an empty repository.
This is not an error. You need merely fill the newly created subdirectory. Then use git add, git commit and git push to push initial content to be visible by other teammates.
When gitolite-admin commits and other activities begin asking for a password, it means something ssh-ugly has happened.
When this happens to a Git user you're administering, it's usually solved by asking him or her to submit a fresh private key from a working host which you commit in the keydir of gitolite-admin.
However, an admin cannot commit a new key for himself or others in this state!
In January, 2012, I think an Ubuntu system update forced me into a situation in which all my keys just went bad. As the gitolite administrator, I could no longer work in gitolite-admin. I tried to re-create my keys, but they still didn't work. (All the while wondering if I could even commit a new key to gitolite-admin anyway.) See my article on ssh key generation and errors using keys, Errors along the way?.
I advise that you not continue unless and until you have mastered the ability to install and use an RSA public key on a remote server.
Once I had access via ssh key working again, I was unable to push a new keyfile to Git via gitolite-admin. I found the following solution.
My original steps...
$ mkdir last-resort $ cd last-resort $ git clone ~/repositories/gitolite-admin.git
Note: This whole nightmare happened to me all over again six months later and I kept what might be better notes for this step in Git Administration ...of broken gitolite-admin. Look back and forth between the new one and the old one here; it might help.
$ gl-dont-panic # (read output...)
$ gl-dont-panic /home/git/last-resort/gitolite-admin/keydir/[email protected]
You should see this:
Cloning into /tmp/tmp.Spusfo8RJI... done. [master 66cb628] emergency add/update russ@main key \ (from /home/git/last-resort/gitolite-admin/keydir/[email protected]) 1 files changed, 1 insertions(+), 1 deletions(-) rewrite keydir/[email protected] (100%) Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 751 bytes, done. Total 4 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. remote: remote: ***** WARNING ***** remote: the following users have no pubkeys: remote: tom To /home/git/repositories/gitolite-admin.git 6f90a93..66cb628 master -> master
$ git config --global user.email "[email protected]" $ git config --global user.name "Russell Bateman"
This got me out of the weeds although, back on my client (development host), I had to clone my gitolite-admin project in another place (than the original), make the changes I had wanted to make there and commit them, which worked. Then I removed the original project. On the server, I also removed the "last-resort" project I cloned to enact the magic.
Life was good again.
Note this peculiarity, however. When you do these commands inside a repository, it changes it for that repository and not for the resource that is your ~/.gitconfig, the configuration that holds in the face of missing configuration no matter what the repository. This sequence of commands may illustrate:
~ $ git config user.name Russell Bateman ~ $ git config user.email [email protected] ~ $ cd dev/flow-editor ~/dev/flow-editor $ git config user.email [email protected] ~/dev/flow-editor $ git config user.email "[email protected]" ~/dev/flow-editor $ git config user.email [email protected] ~/dev/flow-editor $ cd .. ~/dev $ git config user.email [email protected]