I am running a Debian system, and have recently installed gitolite using the DEB package.
Here is my problem:
I have tried to clone the gitolite-admin.git repository (which is used for configuring the gitolite installation for all repositories that are you wish gitolite to manage for you).
My first attempt was exactly how the instructions state:
git clone gitolite@server:gitolite-admin
I received the following error:
fatal: 'gitolite-admin' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Note: This same thing happens if I replace gitolite-admin with gitolite-admin.git
HOWEVER, when I do the following:
git clone gitolite@server:~/repositories/gitolite-admin.git
This line successfully clones the repository to my local workstation.
Now, I have no problem adding the extra text to the filepath, however I am told that this is incorrect by the documentation.
The following link ( http://sitaramc.github.com/gitolite/doc/3-faq-tips-etc.html ) states that "adding repositories/ at the start of the repo name in the git clone" is a common error/mistake. It also states that "In fact gitolite prepends $REPO_BASE internally, so you shouldn't also do the same thing!"
My .gitolite.rc file contains the following line for $REPO_BASE:
[Located in /home/gitolite/.gitolite.rc]
$REPO_BASE="repositories";
My question is, what is wrong with my configuration, that causes the $REPO_BASE not to prepend my git clone?
If you need any further information, please leave a comment stating what info you need and I will be happy to oblige.
Other notes:
- git version: 1.7.2.3
- gitolite version: 1.5.4-2~bp (this is from lenny-backports, because I am using Debian Lenny and gitolite does not come standard with Lenny)
- Debian's installation creates the user "gitolite" to manage gitolite repos with.
Being able to access
gitolite@server:~/repositories/gitolite-admin.git
, but notgitolite@server:gitolite-admin
indicates you are not going “through” Gitolite, but just using plain SSH-based access to the gitolite user.If
ssh gitolite@server echo normal access
yieldsnormal access
, then the key you are using is not restricted to going through Gitolite. If you were going through Gitolite you would see something likebad command: echo normal access
.This can happen if you have a key that you use to SSH into the gitolite user itself and you try to use that same key to authenticate as a Gitolite user. A “normal access” key will be present in gitolite’s
.ssh/authorized_keys
without any special prefix. The line for a key that is configured to go through Gitolite will start likecommand="/path/to/gl-auth-command gitolite-username",…
.If you need normal SSH-based access to the gitolite user and Gitolite-based access, then you should setup separate keys for those purposes so that you can specify which key you want to use with
IdentityFile
options in your.ssh/config
file (maybe alsoIdentitiesOnly
if you find that ssh is using the “wrong” key just because you already have it loaded in your ssh-agent).For example:
Use one of your “default” keys (one of ssh’s defaults (e.g.
~/.ssh/id_rsa
) or some key that you usually have loaded in your ssh-agent) to access Gitolite (i.e. you have the public key in the activekeydir/your-gitolite-user-name.pub
).Generate
~/.ssh/gitolite-user
for use in directly logging into the gitolite user. Usessh -i ~/.ssh/gitolite-user gitolite@server
to login. Or, add a custom entry to~/.ssh/config
:so you can just do
ssh gitolite-user
to login.I had this same error:
The repo had been working but after rolling back using cloning on the server as suggested in the gitolite panic section a couple of the files in the repo had owner root instead of gitolite3.
The fix is to change the ownership back to gitolite3.