Hosting git repositories -- Gitolite allows you to setup git hosting on a central server, with very fine-grained access control and many (many!) more powerful features.
implementation notes
- new sugar role_names() to prefix an "@" to CREATOR, and any role
names listed in the rc file.
- invalidate the cache in rules() if the repo was missing. Without
this, an auto-create operation succeeds the ^C check and calls
new_wild_repo(), but then -- due to the cached rules not containing
a rule for CREATOR, the actual read/write fails.
- treat roles (READERS, WRITERS, etc.) as group names that apply only
to that particular repo. Don't add them to %groups, because that
would screw up caching, but add them in when memberships() is called
for the user.
This is why the membership call for the user also has a reponame
tacked on -- i.e., a user's membership list varied depending on
which repo you're talking about.
- while we're about it, pretend we added "CREATOR = <content of
gl-creator>" as another "role". Makes things so much easier dealing
with "RW+ = CREATOR"
- searching for rules pertaining to foo/CREATOR/bar when looking at
repo foo/sitaram/bar is done backwards from what g2 used to do. G2
used to play tricks with the do-eval'd file using global variables
so that what you get after the do may not even contain 'CREATOR'.
We go the other way. We replace sitaram with CREATOR and start
looking for memberships of *both* foo/sitaram/bar and
foo/CREATOR/bar.
- this doesn't work (because we don't know *what* to replace) for
missing repos if GL_USER is not set. This means that 'gitolite
access ...' queries (which do not set GL_USER) cannot be used
reliably for non-existant repos.
Since a ^C check is the only meaningful one for a non-existent repo,
this means you cannot do that from 'gitolite access'.
'GL_USER=luser gitolite info' will still work though ;-)
all in all, much cleaner and simpler than g2.
1b31c21440