we had usurped the email style syntax to separate multiple keys
belonging to the same person, like sitaram@desktop.pub and
sitaram@laptop.pub. If you have so many users that you need the full
email address to disambiguate some of them (or you want to do it for
just plain convenience), you couldn't.
This patch fixes that in a backward compatible way. See
doc/3-faq-tips-etc.mkd for details.
This feature has *no* warranty, and so no documentation. Not more than
this transcript anyway.
config file:
@prof = u1
@TAs = u2 u3
@students = u4 u5 u6
repo assignments/CREATER/a[0-9][0-9]
C = @students
RW+ = CREATER
RW = WRITERS @TAs
R = READERS @prof
session:
as user "u4":
# check your permissions
$ ssh git@server
PTY allocation request failed on channel 0
hello u4, the gitolite version here is v0.95-31-gbcb14ca
you have the following permissions:
C assignments/CREATER/a[0-9][0-9]
@ @ testing
Connection to localhost closed.
# autovivify repos for assignment 12 and 24
$ git clone git@server:assignments/u4/a12 a12
Initialized empty Git repository in /home/sitaram/t/a12/.git/
Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a12.git/
warning: You appear to have cloned an empty repository.
$ git clone git@server:assignments/u4/a24 a24
Initialized empty Git repository in /home/sitaram/t/a24/.git/
Initialized empty Git repository in /home/gitolite/repositories/assignments/u4/a24.git/
warning: You appear to have cloned an empty repository.
# check what repos you autovivified
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
(u4) assignments/u4/a24
as user "u5":
# check your basic permissions
$ ssh git@server
PTY allocation request failed on channel 0
hello u5, the gitolite version here is v0.95-31-gbcb14ca
you have the following permissions:
C assignments/CREATER/a[0-9][0-9]
@ @ testing
Connection to localhost closed.
# see if you have access to any of u4's repos
$ ssh git@server expand assignments/u4/a[0-9][0-9]
# (no output produced)
as user "u4":
# allow "u5" read access to assignment 12
# note you type in "R u5", hit enter, then hit Ctrl-D. Gitolite
# then produces a confirmation message starting "New perms are:"
$ ssh git@server setperms assignments/u4/a12
R u5
New perms are:
R u5
as user "u5":
# again see if you have access to any u4 repos
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
as user "u4":
# check what permissions you gave to assignment 12
$ ssh git@server getperms assignments/u4/a12
R u5
# add RW access to "u6" to assignment 12
# again, type 'em in, then hit Ctrl-D; and note each time you run
# this you're starting from scratch -- you can't "add to" the
# permissions. Deal with it...
$ ssh git@server setperms assignments/u4/a12
R u5
RW u6
New perms are:
R u5
RW u6
as user "u6":
# check what u4 stuff you have access to
$ ssh git@server expand assignments/u4/a[0-9][0-9]
(u4) assignments/u4/a12
- new_repo now takes a "creater" parameter; if given, this user is
recorded (in a file called "gl-creater") as the creater of the repo.
Only applicable to wildcards
- repo_rights reads "gl-creater" and "gl-perms" to tell you who
created it, and whether you (the $user) are in the list of READERS
or WRITERS
**NOTE** that the mechanism to create/update gl-perms has not been
written yet... (as of this commit)
- parse_acl takes 4 more arguments, all optional. The repo name we're
interested in (set by all except the access reporting function), and
the names to be interpolated as $creater, $readers, writers
- report_basic now knows about the "C" permission and shows it
- auth now autovivifies a repo if the user has "C" and it's a wildcard
match, or (the old case) the user has "W" and it's not a wildcard.
In the former case, the creater is also set
IMPLEMENTATION NOTES:
- the Dumper code now uses a custom hash key sort to make sure
$creater etc land up at the *end*
- a wee bit of duplication exists in the update hook; it borrows a
little code from parse_acl. I dont (yet) want to include all of
gitolite.pm for that little piece...
There's a new "C" permission to let someone *create* a repo that matches
the pattern given in the "repo ..." line. If the word CREATER appears
in the repo pattern, then that is forced to the actual user performing
that operation.
Something like this (we'll discuss READERS and WRITERS later):
repo personal/CREATER/.+
C = @staff
R [foo] = READERS
RW [bar] = WRITERS
...various other permissions as usual...
Delegation checking also changes quite a bit... see comments in code
Implementation: there's also a sneaky little trick we're playing here
with the dumped hash
all of this is prep for the upcoming, all-new, chrome-plated,
"wildrepos" branch :)
- many variables go to gitolite.pm now, and are "our"d into the other
files as needed
- new functions parse_acl, report_basic to replace inlined code
Packaging gitolite for debian requires the rc file to be in /etc/gitolite.
But non-root installs must still be supported, and they need it in $HOME.
This means the rc file is no longer in a fixed place, which needs code to find
the rc file first. See comments inside new file 'gitolite.pm' for details.
The rest of the changes are in the other programs, to replace the hard-coded
rc filename with a call to this new code.
