Gitosis/Gitolite Setup

I have an issue with gitosis and gitolite which I have spen开发者_StackOverflow中文版t many hours researching to no avail. After following setup instructions closely for both products, the common symptom is that the target repository is not being located properly through gitosis/gitolite:

This fails:

$> git clone gitolite@example.com:testing
Cloning into testing...
fatal: 'testing' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

While this works:

$> git clone gitolite@example.com:~/repositories/testing
Cloning into testing...
warning: You appear to have cloned an empty repository.

So specifying the full path works, but this would indicate that somehow we are not running through gitosis/gitolite.

Another possibly related symptom of the problem is that when I connect to the server via ssh after the installation, my connection freezes with this message:

$> ssh gitolite@example.com
PTY allocation request failed on channel 0

Also, when I execute "ssh gitolite@example.com info", I keep getting the GNU info instead of gitolite's info (which I can get if I run '/usr/local/bin/gl-auth-command kreeble' as gitolite on the server). I have confirmed that in user gitolite's .ssh directory, authorized_keys has only one entry which puts me through the gitolite command:

command="/usr/local/bin/gl-auth-command kreeble",no-port-forwarding,\
   no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa long_key_base64_here \ 
   user@machine.local

Any ideas on why I would not be presented with the gitolite prompt? I would appreciate any thoughts on this problem, thank you!

I just had this issue occur. I found it stranger that I just setup gitolite successfully on one mac os x machine I had and with the same setup it failed on another mac os x machine I had. My particular issue was the same when trying to clone gitolite-admin but when trying 'ssh git@localhost info' it would return the gnu info instead of the gitolite info. In the documentation it said this issue was due to the wrong key being used on the server so that gitolite was being bypassed.

Looking further into my issue this wasn't the case. Gitolite was being called fine, in fact using -vvv as part of the ssh command showed this. My issue was that months back in attempts to make gitosis or gitolite work (I don't remember which), I had modified /etc/sshd_config and added 'ForceCommand /usr/local/bin/ssh_session' down at the bottom.

The content of that was was:

#!/bin/bash
export SSH_SESSION=1
if [ -z "$SSH_ORIGINAL_COMMAND" ] ; then
  export SSH_LOGIN=1
  exec login -fp "$USER"
else
  export SSH_LOGIN=
  [ -r /etc/profile ] && source /etc/profile
  [ -r ~/.profile ] && source ~/.profile
  eval exec "$SSH_ORIGINAL_COMMAND"
fi

Which ended up causing ssh to bypass some of the paths for gitolite and had them go diredtly to the shell. Since its possible that I had tried this in older attempts to make either gitosis or gitolite work, it could be that other had tried this previously as well and are now getting this error due to it.

I know only about gitosis, which is the predecessor of gitolite and the problem must be the same. I have experienced the very same problem until I thought it out.

Without gitolite installed, normally git installs repositories in ~git, but ~gitolite installs repos in e.g. ~/gitolite/repositories/testing.git.

It is my understanding that the .git suffix is requried.

gitolite@example.com:testing takes you to ~gitolite/repositories/testing but I guess that the code is written in such a way that it thinks that the repo must be named as testing.git. So it deems it as an error.

gitolite@example.com:~/repositories/testing bypasses this URL rewriting rule, but my guess is that it again looks for ~gitosis/repositories/testing.git.

This time, the error handling seems to be a different code. I think that, when it does not find testing.git, it is coded to return an empty repo.

If you simply add .git suffix, all problems disappear. At least that was my experience with gitosis.

Good luck.