6

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.
6

Being able to access gitolite@server:~/repositories/gitolite-admin.git, but not gitolite@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 yields normal access, then the key you are using is not restricted to going through Gitolite. If you were going through Gitolite you would see something like bad 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 like command="/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 also IdentitiesOnly 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 active keydir/your-gitolite-user-name.pub).

Generate ~/.ssh/gitolite-user for use in directly logging into the gitolite user. Use ssh -i ~/.ssh/gitolite-user gitolite@server to login. Or, add a custom entry to ~/.ssh/config:

Host gitolite-user
              User gitolite
          HostName server
      IdentityFile ~/.ssh/gitolite-user
    IdentitiesOnly yes

so you can just do ssh gitolite-user to login.

| improve this answer | |
  • This post was actually very helpful in getting me on the right track. You are absolutely correct -- I was not going "through" Gitolite. One of my issues apparently also was that I ran gl-setup with a user other than the gitolite user, yet was still following the instructions to clone by using the gitolite user. By cloning from the gl-setup user (the user that was listed with that special command="..." stuff) I was able to successfully get in "through" gitolite. Thank you. – invalidsyntax May 18 '11 at 12:50
0

I had this same error:

fatal: 'gitolite-admin' does not appear to be a git repository

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.

gitolite-admin.git# ls -l
total 48
drwx------  2 gitolite3 gitolite3 4096 Mar 27  2012 branches
-rw-r--r--  1 gitolite3 gitolite3    6 Mar 27  2012 COMMIT_EDITMSG
-rw-------  1 gitolite3 gitolite3  119 Jul 12  2013 config
-rw-r--r--  1 gitolite3 gitolite3   73 Aug 25  2013 description
-rw-r--r--  1 gitolite3 gitolite3  128 Aug 23 20:44 gl-conf
-rw-------  1 root      root        23 Aug 26 13:45 HEAD
drwx------  2 gitolite3 gitolite3 4096 Aug 25  2013 hooks
-rw-------  1 root      root       605 Aug 26 13:45 index
drwx------  2 gitolite3 gitolite3 4096 Mar 27  2012 info
drwxr-xr-x  3 gitolite3 gitolite3 4096 Mar 27  2012 logs
drwx------ 83 gitolite3 gitolite3 4096 Aug 26 14:01 objects
drwx------  4 gitolite3 gitolite3 4096 Mar 27  2012 refs

The fix is to change the ownership back to gitolite3.

gitolite-admin.git# chown -R gitolite3:gitolite3 *
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.