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.
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.
gl-shell-setup has a "run as hosting user" piece that basically
automates the adding of the user's (new) key to the admin repo.
This is now gone. (It's not that hard to automate yourself if you want
to do it anyway, using gl-admin-push).
I did this because I needed to allow someone in through a gateway, and
realised that that has the exact same needs. So the whole scheme has
been changed to treat the proxy and the gitolite host as being two
different servers.
At that point it became cumbersome to do the second bit, and I left it
out.
Other changes:
- you can define exceptions for the default shell in gl-shell
- the doc has been simplified.
I got tired of being told "TL;DR". Now the online versions of most
documents fit on a page or two, or at least most of them do. The rest
has been split out (and you can see the links to the split out sections
right where the text is in the raw Markdown).
This is much more pleasant to read, and I've improved the linking so
it's much less effort for me to keep the links correct.
Normally, I use the word "user" in gitolite to mean *my* users, who are
actually admins on their setups. All my documentation has been geared
to that class of person.
Last night my most famous "user" (not "admin", a real gitolite user)
mentioned that he found it very hard to find info on what a *user* could
do, and he was right. So here goes...
