diff --git a/doc/gitolite.rc.mkd b/doc/gitolite.rc.mkd index f42e9d7..ef6f220 100644 --- a/doc/gitolite.rc.mkd +++ b/doc/gitolite.rc.mkd @@ -162,7 +162,7 @@ on feedback from my users to find or fix issues. NOTE that due to some quoting and interpolation issues I have not been able to look at, a literal "." needs to be specified in this string as `\\.` (two backslashes and a dot). So this is how you'd allow any keys in - the "foo" category: `$GL_GITCONFIG_KEYS = "foo\\..*";` + the "foo" section: `$GL_GITCONFIG_KEYS = "foo\\..*";` * `$GL_NO_CREATE_REPOS`, boolean, default 0 @@ -309,10 +309,10 @@ on feedback from my users to find or fix issues. * `$GL_WILDREPOS_PERM_CATS`, string, default "READERS WRITERS" Originally, we only allowed "R" and "RW" in the setperms command. Now we - allow the admin to define other categories as she wishes (example: - MANAGERS, TESTERS, etc). + allow the admin to define other roles as she wishes (example: MANAGERS, + TESTERS, etc). - This variable is a space-separated list of the allowed categories. + This variable is a space-separated list of the allowed roles. PLEASE, *PLEASE*, read the section in [doc/wildcard-repositories.mkd][wild] for caveats and warnings. This is a @@ -324,8 +324,8 @@ on feedback from my users to find or fix issues. $GL_WILDREPOS_PERM_CATS = "READERS WRITERS"; - You can use your own categories in addition to the standard ones; I - suggest you include READERS and WRITERS for backward compatbility though: + You can use your own roles in addition to the standard ones; I suggest you + include READERS and WRITERS for backward compatbility though: $GL_WILDREPOS_PERM_CATS = "READERS WRITERS MANAGERS TESTERS"; diff --git a/doc/wildcard-repositories.mkd b/doc/wildcard-repositories.mkd index 3f18225..52e33c0 100644 --- a/doc/wildcard-repositories.mkd +++ b/doc/wildcard-repositories.mkd @@ -21,7 +21,7 @@ In this document: * side-note: line-anchored regexes * contrast with refexes * handing out rights to wildcard-matched repos - * (admin) adding other categories than READERS and WRITERS + * (admin) adding other roles than READERS and WRITERS * **IMPORTANT WARNING ABOUT THIS FEATURE** * setting a gitweb description for a wildcard-matched repo * reporting @@ -175,10 +175,10 @@ part of this list*** is controlled by the person who created the repository. The use case is that, although our toy example has only 3 students, in reality there will be a few dozen, but each assignment will be worked on only by a handful from among those. This allows the creator to take ad hoc sets of -users from among the actual users in the system, and place them into one of -two categories (in this example, READERS and WRITERS respectively). In theory -you could do the same thing by creating lots of little "assignment-NN" groups -in the config file but that may be a little too cumbersome for non-secret +users from among the actual users in the system, and give them one of two +roles (in this example, READERS and WRITERS respectively). In theory you +could do the same thing by creating lots of little "assignment-NN" groups in +the config file but that may be a little too cumbersome for non-secret environments. Create a small text file that contains the permissions you desire: @@ -208,13 +208,13 @@ The following points are important: `:` like in a repo URL. The first space-separated word is READERS or WRITERS, and the rest are simple usernames. - + -### (admin) adding other categories than READERS and WRITERS +### (admin) adding other roles than READERS and WRITERS -Let's say your needs are more complex and you need more categories of users. -For example, you might like to have a setup where only a tester can update -tags, and only a manager can delete branches: +Let's say your needs are more complex and you need more roles. For example, +you might like to have a setup where only a tester can update tags, and only a +manager can delete branches: repo foo/..* C = u1 @@ -241,14 +241,13 @@ file. The rc file documentation (`doc/gitolite.rc.mkd`) explains how. #### **IMPORTANT WARNING ABOUT THIS FEATURE** -Please make sure that none of the category names conflict with any of the +Please make sure that none of the role names conflict with any of the **usernames** in the system. For example, if you have a user called "foo", -make sure you do not include "foo" as a valid category in +make sure you do not include "foo" as a valid role in `$GL_WILDREPOS_PERM_CATS`. -You can keep things sane by using UPPERCASE names for categories, while -keeping all your usernames lowercase; then you don't have to worry about this -problem. +You can keep things sane by using UPPERCASE names for roles, while keeping all +your usernames lowercase; then you don't have to worry about this problem. @@ -309,7 +308,7 @@ Now find a repo pattern that matches the actual reponame being pushed -- this tells you which set of rules to apply. There can be multiple matches; if so, they will all be applied in the sequence they appear in the config file. -If the invoking user has been put in the "WRITERS" category using `setperms`, all +If the invoking user has been given the "WRITERS" role using `setperms`, all permissions for the the user WRITERS are given to the invoking username (and similarly for READERS). @@ -330,8 +329,8 @@ Assuming user "u4" trying to push-create a new repo called RW = @TAs R = @prof -If u4 puts u5 in the "WRITERS" category using `setperms`, and u5 tries to -access that repo, the ruleset looks like: +If u4 gives u5 the "WRITERS" role using `setperms`, and u5 tries to access +that repo, the ruleset looks like: repo assignments/u4/a23 C = @students