109 lines
3.5 KiB
Markdown
109 lines
3.5 KiB
Markdown
# special features and setups
|
|
|
|
----
|
|
|
|
[[TOC]]
|
|
|
|
----
|
|
|
|
## #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.
|
|
|
|
## #pushhook updating hooks via the admin repo
|
|
|
|
Gitolite by default maintains the distinction between someone who can push to
|
|
the admin repo and someone who has shell access to the server. As a result,
|
|
you cannot change any hooks merely by pushing the admin repo.
|
|
|
|
But some people don't care about this and want to do it anyway. Besides,
|
|
there *is* one advantage: your hooks can also be versioned now.
|
|
|
|
So here's how to add/change hooks when you push the gitolite-admin repo:
|
|
|
|
1. Put all common hooks in a new directory called 'common-hooks'.
|
|
|
|
2. Create a trigger program called 'propagate-hooks' in 'src/triggers' that
|
|
contains this:
|
|
|
|
#!/bin/sh
|
|
|
|
cd $GL_ADMIN_BASE
|
|
cp -a common-hooks/* hooks/common
|
|
|
|
gitolite setup --hooks-only
|
|
|
|
3. Add this to the `POST_COMPILE` trigger list in the rc file.
|
|
|
|
And that should be it, pretty much.
|
|
|
|
If you have lots of repos this is inefficient -- because the hook fixup will
|
|
run on *any* change to the admin repo, even if the change has nothing to do
|
|
with hooks.
|
|
|
|
If you're concerned about this, put the script in 'src/commands' instead of
|
|
'src/triggers'. (You might want to add some access control; see other
|
|
commands for inspiration, but it's not really needed in this case).
|
|
|
|
Then, whenever any hooks have changed, the admin can run
|
|
|
|
ssh git@host propagate-hooks
|