Gitolite git clone error

Question

I am trying to setup gitolite on my server (Macos server).

I followed the instructions in the INSTALL document found here : http://sitaramc.github.com/gitolite/doc/1-INSTALL.html

I installed the root method.

I got everything setup (ssh pubkey authentication and default gitolite setup)

$ssh git@server info
hello admin, the gitolite version here is v1.5.9.1-27-gb97115f
the gitolite config gives you the following access:
     R   W  gitolite-admin
    @R_ @W_ testing

According to installation instruction I should be able to checkout a repository.

But when I try to clone the gitolite-admin repositry I get an error:

$ git clone git@server:gitolite-admin
Cloning into gitolite-admin...
Assertion failed: (argv0_path), function system_path, file exec_cmd.c, line 27.
error: git-shell died of signal 6
fatal: The remote end hung up unexpectedly

I got the latest git version of gitolite and git v. 1.7.3.4

Can anybody help me?

Edit 1: added git clone command before error message

Answer 1

The OP skipper3k reports an issue with RUNTIME_PREFIX in Git, a bit similar to "git pull broken" question:

I'm not sure whether RUNTIME_PREFIX is defined for you. But while nosing in the Makefile, I did notice that prefix defaults to $(HOME). I suspect that this may be the cause of your problems.

The simple answer is to put this in ~/.bashrc:

export GIT_EXEC_PATH=/opt/local/libexec/git-core

If you want to find out more about what's going on, you'll probably have to recompile git using port -d upgrade -f git-core (or similar) and look closely at the build log to see where prefix is being set.
Incidentally, port cat git-core shows heavy usage of ${prefix}.

---

Original answer:

First, did you get the most up-to-date gitolite version?
At https://github.com/sitaramc/gitolite/, you need to consider the 'pu' branch.

The installation documentation is then this one.

---

GitoliteV3 or 'g3' doc:

"Installation" consists of the following options:

1. Keep the sources anywhere and use the full path to run the gitolite command.
2. Keep the sources anywhere and symlink just the gitolite program to some directory on your $PATH.
3. Copy the sources somewhere and use that path to run the gitolite command.

You can run the 'install' command in 3 different ways:

# option 1
gitolite/install

# option 2
gitolite/install -ln
# defaults to $HOME/bin, or use a specific directory:
gitolite/install -ln /usr/local/bin

# option 3
gitolite/install -to /usr/local/gitolite/bin

---

Old answer for gitolite V2: Second, I prefer the "from-client method" method:

The advantage of this method is that it forces you to solve the ssh pubkey problem before attempting to install.
It works best if you have dedicated userids,

• one on the server for installing gitolite,
• and one on the client for administering it.

The disadvantage is that the admin user ends up with two keys

• one for shell access (that he started with) and
• one for gitolite access (which the script creates if needed).

So I like to create a ~/.ssh/config file with the two different sets of parameters:

host gitolite
     user git
     hostname server
     identityfile ~/.ssh/git
host gitadmin
     user git
     hostname server
     identityfile ~/.ssh/id_rsa (myaccount public key)

The gitolite-admin is only visible for the first public ssh key:

C:\HOMEWARE\git>ssh gitolite
hello git, the gitolite version here is v1.5.9-25-ga10287a
the gitolite config gives you the following access:
     R   W      gitolite-admin
    @R_ @W_     testing
Connection to server closed.

With my account:

C:\HOMEWARE\git>ssh gitadmin
hello myaccount, the gitolite version here is v1.5.9-25-ga10287a
the gitolite config gives you the following access:
    @R_ @W_     testing
Connection to mccprdgit10 closed.

So:

C:\HOMEWARE\git>git clone gitolite:gitolite-admin
Cloning into gitolite-admin...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 16 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (16/16), done.
Resolving deltas: 100% (2/2), done.

Answer 2

I pretty much tried anything I could think of and couldn't get it to work...until I noticed somewhere that GIT is very high on email addresses...so I regenerated my ssh keypair using the -C option:

ssh-keygen -t rsa -C "[e-mail]"

Low and behold, all of a sudden I could clone gitolite-admin without any problem.

Apparently the email in .gitconfig's user.email key MUST correspond to the email that was used to generate the SSH key. Honestly, if you only have 1 keypair in your .ssh folder, why on earth does it matter that the email corresponds? Imho, if you pass a key and the key is in the authorized_keys on the server, it should work regardless of the .gitconfig user.email property.

Answer 3

The problem was with the way git was compiled on mac. I had to manually compile git without the RUNTIME_PREFIX set. Now it works.

Answer 4

To pile on, as a solution for Gitolite v3, for Mac Lion, this is what worked for me:

$ENV{PATH}="/usr/local/bin:$ENV{PATH}";

Add it to ~/.gitolite.rc for the git user on the server. Make sure it is before the "1;" at the end.

As detailed in: https://serverfault.com/questions/307493/cant-clone-gitolite-admin

The solutions involving GIT_PATH are outdated, according to: http://sitaramc.github.com/gitolite/g2migr.html

Answer 5

It seems the correct fix to this error is to add

$ENV{GIT_EXEC_PATH} = "/usr/libexec/git-core";

to your .gitolite.rc file.

Answer 6

Having just dealt with this for a third time after forgetting the first two times, I figure it can't be unusual.

$ git clone git@hugo:gitolite-admin
Cloning into gitolite-admin...
fatal: The remote end hung up unexpectedly

At least one reason for this is that the gitolite user must have a login shell - making a system user won't work for some reason.. it just falls over, causing the error above.

Also, for the ssh test, you must switch off PTYs on the command line otherwise ssh simply won't work - I think maybe it worked with older versions of ssh but doesn't on anything I have:

$ ssh git@hugo
PTY allocation request failed on channel 0

$ ssh -T git@hugo
hello key, this is git@hugo running gitolite3 v3.01-10-g699bafa on git 1.7.10

(why it thinks I'm called 'key' is another config issue I haven't solved yet).