103 lines
3.3 KiB
Markdown
103 lines
3.3 KiB
Markdown
# special features and setups
|
|
|
|
----
|
|
|
|
[[TOC]]
|
|
|
|
----
|
|
|
|
## #elsewhere putting 'repositories' and '.gitolite' somewhere else
|
|
|
|
Gitolite insists that the "repositories" and ".gitolite" directories be in
|
|
`$HOME`. If you want them somewhere else:
|
|
|
|
* do the install as normal,
|
|
* *then* move those directories to wherever you want and replace them with
|
|
symlinks pointing to the new location.
|
|
|
|
## #writable disabling pushes to take backups
|
|
|
|
The `writable` command allows you to disable pushes to all repos or just the
|
|
named repo, in order to do file-system level things to the repo directory that
|
|
require it not to change, like using normal backup software.
|
|
|
|
Run `gitolite writable -h` for more info.
|
|
|
|
## #pers "personal" branches
|
|
|
|
"personal" branches are great for environments where developers need to share
|
|
work but can't directly pull from each other (usually due to either a
|
|
networking or authentication related reason, both common in corporate setups).
|
|
|
|
Personal branches exist **in a namespace** of their own. The syntax is
|
|
|
|
RW+ personal/USER/ = @userlist
|
|
|
|
where the "personal" can be anything you like (but cannot be empty), and the
|
|
"/USER/" part is **necessary (including both slashes)**.
|
|
|
|
A user "alice" (if she's in the userlist) can then push any branches inside
|
|
`personal/alice/`. Which means she can push `personal/alice/foo` and
|
|
`personal/alice/bar`, but NOT `personal/alice`.
|
|
|
|
(Background: at runtime the "USER" component will be replaced by the name of
|
|
the invoking user. Access is determined by the right hand side, as usual).
|
|
|
|
Compared to using arbitrary branch names on the same server, this:
|
|
|
|
* Reduces namespace pollution by corralling all these ad hoc branches into
|
|
the "personal/" namespace.
|
|
* Reduces branch name collision by giving each developer her own
|
|
sub-hierarchy within that.
|
|
* Removes the need to think about access control, because a user can push
|
|
only to his own sub-hierarchy.
|
|
|
|
## delegating access control responsibilities
|
|
|
|
See [this][deleg].
|
|
|
|
## #keysonly using pubkeys obtained from elsewhere
|
|
|
|
If you're not managing keys via the gitolite-admin repo, but getting them from
|
|
somewhere else, you'll want to periodically "update" the keys.
|
|
|
|
To do that, first edit your rc file and add something like this:
|
|
|
|
SSH_AUTHKEYS =>
|
|
[
|
|
'post-compile/ssh-authkeys',
|
|
],
|
|
|
|
Then write a script that
|
|
|
|
* gets all the keys and dumps them into `$HOME/.gitolite/keydir` (or into a
|
|
subdirectory of it).
|
|
|
|
* runs `gitolite trigger SSH_AUTHKEYS`.
|
|
|
|
Run this from cron or however you want.
|
|
|
|
## #gh giving users their own repos
|
|
|
|
(Please see [this][wild] for background on the ideas in this section).
|
|
|
|
It's very easy to give users their own set of repos to create, with the
|
|
username at the top level. The simplest setup is:
|
|
|
|
repo CREATOR/..*
|
|
C = @all
|
|
RW+ = CREATOR
|
|
RW = WRITERS
|
|
R = READERS
|
|
|
|
Now users can create any repo under their own name simply by cloning it or
|
|
pushing to it, then use the [perms][] command to add other users to their
|
|
WRITERS and READERS lists.
|
|
|
|
Of course you can get much more creative if you add a few more roles (see
|
|
"roles" in [this][wild] page).
|
|
|
|
<font color="gray">(I prefer using some prefix, say "u", as in `repo
|
|
u/CREATOR/..*`. This helps to keep user-created repos separate, and avoid
|
|
name clashes in some far-fetched scenarios).</font>
|