Have a user, whose public key was successfully added under “gitolite-admin/keydir” and whose rights were successfully configured under “gitolite-admin/conf/gitolite.conf”.
When this very user is cloning an existing, correctly configured repository, his/her identity ( public key ) is not being passed correclty => hence notice a password prompt:
$ git clone git@yourgitserver.com:your-project
Cloning into your-project...
git@yourgitserver.com's password:
fatal: 'your=project' does not appear to be a git repository
fatal: The remote end hung up unexpectedly |
$ git clone git@yourgitserver.com:your-project
Cloning into your-project...
git@yourgitserver.com's password:
fatal: 'your=project' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
Here is the way to help out git / gitolite to understand which identity ( key ) to use:
host gitolite
user git
hostname yourgitserver.com
identityfile ~/.ssh/mypubkey |
host gitolite
user git
hostname yourgitserver.com
identityfile ~/.ssh/mypubkey
Now changing “git@yourgitserver.com” to “gitolite” does the trick:
$ git clone gitolite:your-project
Cloning into your-project...
remote: Counting objects: 83, done.
remote: Compressing objects: 100% (77/77), done.
remote: Total 83 (delta 3), reused 0 (delta 0)
Receiving objects: 100% (83/83), 156.45 KiB | 49 KiB/s, done.
Resolving deltas: 100% (3/3), done. |
$ git clone gitolite:your-project
Cloning into your-project...
remote: Counting objects: 83, done.
remote: Compressing objects: 100% (77/77), done.
remote: Total 83 (delta 3), reused 0 (delta 0)
Receiving objects: 100% (83/83), 156.45 KiB | 49 KiB/s, done.
Resolving deltas: 100% (3/3), done.
Notice, public key was successfully accepted => hence there was no password prompt, and the clone was successful.