deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

README: added para about selective rewind, plus some minor fixes

Browse source
This commit is contained in:
Sitaram Chamarty 2009-08-28 18:29:05 +05:30
parent 4bea8a9ae7
commit 23e4c209eb
1 changed files with 19 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
README.mkd
View file

@ -23,7 +23,7 @@ a typical $DAYJOB setting, there are some issues:
and be done and be done
* often, "python-setuptools" isn't installed (and on a Solaris9 I was trying * often, "python-setuptools" isn't installed (and on a Solaris9 I was trying
to help remotely, we never did manage to install it eventually) to help remotely, we never did manage to install it eventually)
* the most requested feature (see "what's extra?") had to be written anyway * the most requested feature (see "what's new?") had to be written anyway
### what's gone ### what's gone
@ -45,15 +45,17 @@ Per-branch permissions. You will not believe how often I am asked this at
$DAYJOB. This is almost the single reason I started *thinking* about rolling $DAYJOB. This is almost the single reason I started *thinking* about rolling
my own gitosis in the first place. my own gitosis in the first place.
It's not just "read-only" versus "read-write". Rewinding a branch (aka "non
fast forward push") is potentially dangerous, but sometimes needed. So is
deleting a branch (which is really just an extreme form of rewind). I needed
something in between allowing anyone to do it (the default) and disabling it
completely (`receive.denyNonFastForwards` or `receive.denyDeletes`).
Take a look at the example config file in the repo to see how I do this. I Take a look at the example config file in the repo to see how I do this. I
copied the basic idea from `update-hook-example.txt` (it's one of the "howto"s copied the basic idea from `update-hook-example.txt` (it's one of the "howto"s
that come with the git source tree). This includes not just who can push to that come with the git source tree). However, please note the difference in
what branch, but also whether they are allowed to rewind it or not (non-ff the size and complexity of the *operational code* between the update hook in
push). that example, and in mine :-) The reason is in the next section.
However, please note the difference in the size and complexity of the
*operational code* between the update hook in that example, and in mine :-)
The reason is in the next section.
### the workflow ### the workflow
@ -71,8 +73,7 @@ So I changed the workflow completely:
* all admin changes happen *on the server*, in a special directory that * all admin changes happen *on the server*, in a special directory that
contains the config and the users' pubkeys. But there's no commit and contains the config and the users' pubkeys. But there's no commit and
push afterward. Nothing prevents you from version-controlling that push afterward
directory if you wish to, but it's not *required*
* instead, after making changes, you "compile" the configuration. This * instead, after making changes, you "compile" the configuration. This
refreshes `~/.ssh/authorized_keys`, as well as puts a parsed form of the refreshes `~/.ssh/authorized_keys`, as well as puts a parsed form of the
access list in a file for the other two pieces to use. access list in a file for the other two pieces to use.
@ -80,15 +81,20 @@ So I changed the workflow completely:
The pre-parsed form is basically a huge perl variable. It's human readable The pre-parsed form is basically a huge perl variable. It's human readable
too (never mind what the python guys say!) too (never mind what the python guys say!)
Advantages: all the complexity of parsing and error checking the parse is done So the admin knows immediately if the config file had any problems, which is
away from the two places where the actual access control happens, which are: good. Also, the relatively complex parse code is not part of the actual
access control points, which are:
* the program that is run via `~/.ssh/authorized_keys` (I call it * the program that is run via `~/.ssh/authorized_keys` (I call it
`gl-auth-command`, equivalent to `gitosis-serve`); this decides whether `gl-auth-command`, equivalent to `gitosis-serve`); this decides whether
git should even be allowed to run (basic R/W/no access) git should even be allowed to run (basic R/W/no access)
* the update-hook on each repo, which decides the per-branch permissions * the update-hook on each repo, which decides the per-branch permissions
---- ### footnotes
[1] I hate whitespace to mean anything significant except for text; this is a [1] I hate whitespace to mean anything significant except for text; this is a
personal opinion *only*, so pythonistas please back off :-) personal opinion *only*, so pythonistas please back off :-)
### contact
sitaramc@gmail.com