Gitolite Access Repair

Gitolite access repair

If you have version 2.0.3 or later installed, you can use the gl-admin-push command to push from a local clone of the admin repository:

See gl-admin-push: bypassing gitolite for the gitolite-admin repo :

su to your Gitolite user
cd /tmp && git clone ~/repositories/gitolite-admin.git
replace your old public key in keydir/ with your new one, then commit
~/.gitolite/src/gl-admin-push to push it; this will update the user’s .ssh/authorized_keys to integrate your new key

If you are using something earlier than 2.0.3, you can use the gl-dont-panic command to replace a key:

su to your Gitolite user
copy your new public key to /tmp/username.pub
username.pub should be the same as a filename that is currently in your keydir/; you can list the contents of the existing keydir/ with
```
GIT_DIR="$HOME"/repositories/gitolite-admin.git git ls-tree master:keydir
```
run cd /tmp && ~/.gitolite/src/gl-dont-panic username.pub to install the replacement key

Locked out of gitolite and cant gl-admin-push

The OP Purplefish32 realized that this message can also occur if the user executing the the gl-admin-push hasn't its public key properly registered.

That key needs to be set with the gitolite force-command script.

command="/home/git/bin/gl-auth-command myusername",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

This is consistent with what that script does:

# if GL_BINDIR was not passed in, find it
[ -z "$GL_BINDIR" ] &&
    GL_BINDIR=`  perl -ne 'print($1), exit if /^command="(.+?)\/gl-(time|auth-command) /' < $HOME/.ssh/authorized_keys`
# GL_BINDIR still not known?  we have a problem...
[ -z "$GL_BINDIR" ] && {
    echo "

Unable to determine correct path for gitolite scripts from the authkeys file.

EGit SSH Exception caught during execution of ls-remote command

git:// and ssh:// use different protocols (see EGit User_Guide#Git_URLs). So either use the former in EGit too or make sure ssh access works.

Git: How to solve Permission denied (publickey) error when using Git?

If the user has not generated a ssh public/private key pair set before

This info is working on theChaw but can be applied to all other git repositories which support SSH pubkey authentications. (See [gitolite][1], gitlab or github for example.)

First start by setting up your own public/private key pair set. This
can use either DSA or RSA, so basically any key you setup will work.
On most systems you can use ssh-keygen.

First you'll want to cd into your .ssh directory. Open up the terminal and run:
cd ~/.ssh && ssh-keygen
Next you need to copy this to your clipboard.
On OS X run: cat id_rsa.pub | pbcopy
On Linux run: cat id_rsa.pub | xclip
On Windows (via Cygwin/Git Bash) run: cat id_rsa.pub | clip
On Windows (Powershell) run: Get-Content id_rsa.pub | Set-Clipboard (Thx to @orion elenzil)
Add your key to your account via the website.
Finally setup your .gitconfig.
git config --global user.name "bob"
git config --global user.email bob@...
(don't forget to restart your command line to make sure the config is reloaded)
That's it you should be good to clone and checkout.

Further information can be found at https://help.github.com/articles/generating-ssh-keys (thanks to @Lee Whitney)
[1]: https://github.com/sitaramc/gitolite

If the user has generated a ssh public/private key pair set before

check which key have been authorized on your github or gitlab account settings
determine which corresponding private key must be associated from your local computer

eval $(ssh-agent -s)

define where the keys are located

ssh-add ~/.ssh/id_rsa

git: can't push (unpacker error) related to permission issues

I had this error for two weeks, and the majority of the solutions stated 'chmod -R' as the the answer, unfortunately for me my git repos (local / remote / shared - with team) were all on Windows OS, and even though chmod -Rv showed all the files changed to 'rwxrwxrwx', a subsequent 'ls -l' still showed all files as 'rwxr-xr-x' and the error repeated itself. I eventually saw this solution by Ariejan de Vroom. It worked and we were all able to pull and push again.

On both local (the local that is having trouble pushing) and remote repos, run the following commands:

$ git fsck
$ git prune
$ git repack
$ git fsck

On a side note, I tried using Windows' native file permissions / ACL and even resorted to elevating the problem user to Administrator, but none of that seemed to help. Not sure if the environment is important, but it may help someone with a similar setup - problem team member and remote (Windows Server 2008 R2 Standard), my local (Windows 7 VM).

git branch permissions

Git does not have branch specific permissions. You can either make the whole repository read only to the people or create one private and one public repository and only push the development branch to the public on while keeping the master only in your private repository.

Edit:
For branch specific permissions, you need a server-side authorization layer like Gitolite — obviously, this requires you to be managing your own Git server.

Eclipse Git (EGit) unable to clone Git repository

If you are using the SSH protocol (I saw you use "ssh git@af-blackpearl.site"), you should choose "ssh" in protocol. The repository name is myproject (no .git part)

How to use group file permissions correctly on a git repository?

You need to set the setgid bit on the group as well.


chgrp -R GROUP /path/to/repo
find /path/to/repo -type d -print0 | xargs -0 chmod g+s

Gitolite Access Repair