Please don't use this setting in a production system but in some environments it is needed for completely automated *testing* to be able to use ssh correctly.
John from kernel.org wanted this; for details see  : http://groups.google.com/group/gitolite/browse_thread/thread/daf92ef85d121234
Thanks to Kacper Kornet for catching this... (by the way, there's a simple workaround if you are affected by this but can't upgrade to this commit or later: just create an empty $PROJECTS_LIST file, which is by default ~/projects.list)
If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will get caught later when someone whom youhave given that role tries to access the repo (look for another occurrence of the same error message as this one). So there's no access violation but it would be nice to be told upfront that it won't work.
...if you called check_config_key() from new_repo()
thanks to Heiko Carstens for convincing me there are valid workflows that need this feature (forgot to put this in the earlier commit)
Signed-off-by: Stefan Naewe <email@example.com>
And the quick install instructions should really show the "-q"...
Signed-off-by: Jari Aalto <firstname.lastname@example.org>
Using a username in an unused group name will still cause the warning, but the message was misleading in that context
When a slave receives a mirror push (git-receive-pack), set the GL_REPO environment variable so that custom hooks can use it.
Apparently some people want gitolite-admin as a non-repo. Completely outside gitolite, managed by puppet or such, and leaving only symlinks for 'conf' and 'keydir' in $GL_ADMINDIR. But then when they have to run 'gl-setup', the 'git add' complains about the symlink. Hence this patch. ---- Meanwhile, if you're one of those puppet masters, here's the script I gave them for the *compile* (this has nothing to do with this patch; I'm just throwing it in here so I won't lose it): #!/bin/bash # let's say you install using "non-root" method. (Adjust GL_BINDIR for root # method or package method). # install normally, then make changes directly in $GL_ADMINDIR/conf and # $GL_ADMINDIR/keydir. (Please leaves "logs/" and "hooks/" alone). # Then run this: export GL_ADMINDIR=$HOME/.gitolite export GL_BINDIR=$HOME/bin export GL_RC=$HOME/.gitolite.rc cd $GL_ADMINDIR $GL_BINDIR/gl-compile-conf # BE SURE TO REMOVE THE ADMIN REPO ITSELF FROM conf/gitolite.conf, as well as # repositories/gitolite-admin.git, lest a push by someone end up overwriting # this hand- (or machine-) crafted config. # you can get away even further from gitolite's control. You can, for # example, set GL_NO_SETUP_AUTHKEYS in the rc file, and manage even the keys # yourself. Just put the full path to $GL_BINDIR/gl-auth-command followed by # the username in the "command=" part of the authkeys file you generate.
since gl-shell-setup runs as root, the comment in the generated key was 'root@...' instead of whatever userid it was being created for. This does not affect gitolite or ssh but it seems some people don't treat "comment" and "comment" and actually *do* stuff with it. (only code is from author; commit message is from committer)
(can_* == can_read, can_write, and can_create) See top of contrib/adc/adc.common-functions for more on this. Note: the old style (calling get_rights_and_owner with $repo, then checking $perm_read, $perm_write, etc.), will still work fine.
missed this one when I did c5f342a (sshkeys-lint total rewrite, and gl-setup now uses it)