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

doc fixes related to conf and rc getting their own doc files

Browse source
This commit is contained in:
Sitaram Chamarty 2011-01-27 19:27:36 +05:30
parent 81f39bd64c
commit d2cef2d05e
7 changed files with 21 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/2-admin.mkd
View file

@ -59,7 +59,7 @@ Once you've cloned it, you're ready to add users and repos.
if you wish, since the entire tree is searched. if you wish, since the entire tree is searched.
* edit the config file (`conf/gitolite.conf` in your admin repo clone). See * edit the config file (`conf/gitolite.conf` in your admin repo clone). See
`conf/example.conf` in the gitolite source for details on what goes in `doc/gitolite.conf.mkd` in the gitolite source for details on what goes in
that file, syntax, etc. Just add new repos as needed, and add new users that file, syntax, etc. Just add new repos as needed, and add new users
and give them permissions as required. The users names should be exactly and give them permissions as required. The users names should be exactly
the same as their keyfile names, but without the `.pub` extension the same as their keyfile names, but without the `.pub` extension
@ -336,7 +336,7 @@ very easily. For security reasons, this can only be done from the master
config file (i.e., if you're using delegation, the delegated admins cannot config file (i.e., if you're using delegation, the delegated admins cannot
specify git config settings). specify git config settings).
Please see `conf/example.conf` for syntax. Note that this only supports the Please see `doc/gitolite.conf.mkd` for syntax. Note that this only supports the
basic forms of the "git config" command: basic forms of the "git config" command:
git config section.key value # value may be an empty string git config section.key value # value may be an empty string

4
doc/3-faq-tips-etc.mkd
View file

@ -81,7 +81,7 @@ seem to hurt anything. [Update 2009-09-14; this has been fixed in git
#### `@all` syntax for repos #### `@all` syntax for repos
There *is* a way to use the `@all` syntax for repos also, as described in There *is* a way to use the `@all` syntax for repos also, as described in
`conf/example.conf`. However, there are a couple of minor cautions: `doc/gitolite.conf.mkd`. However, there are a couple of minor cautions:
* don't use `NAME/` or such restrictions on the special `@all` repo. Due to * don't use `NAME/` or such restrictions on the special `@all` repo. Due to
the potential for defeating a crucial optimisation and slowing down *all* the potential for defeating a crucial optimisation and slowing down *all*
@ -300,7 +300,7 @@ is still determined by the right hand side of course.
You can specify hooks that you want to propagate to all repos, as well as You can specify hooks that you want to propagate to all repos, as well as
per-repo "gitconfig" settings. Please see `doc/2-admin.mkd` and per-repo "gitconfig" settings. Please see `doc/2-admin.mkd` and
`conf/example.conf` for details. `doc/gitolite.conf.mkd` for details.
<a name="_bypassing_gitolite"></a> <a name="_bypassing_gitolite"></a>

2
doc/gitolite.rc.mkd
View file

@ -120,7 +120,7 @@ on feedback from my users to find or fix issues.
This setting allows the repo admin to define acceptable gitconfig keys. This setting allows the repo admin to define acceptable gitconfig keys.
Gitolite allows you to set git repo options using the "config" keyword; Gitolite allows you to set git repo options using the "config" keyword;
see conf/example.conf for details and syntax. see doc/gitolite.conf.mkd for details and syntax.
However, if you are in an installation where the repo admin does not (and However, if you are in an installation where the repo admin does not (and
should not) have shell access to the server, then allowing him to set should not) have shell access to the server, then allowing him to set

10
doc/progit-article.mkd
View file

@ -47,7 +47,7 @@ That last command does produce a fair amount of output, which might be interesti
### Customising the Install ### ### Customising the Install ###
While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step. The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses. This "rc" file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue. This file also contains various settings that you can change to enable or disable some of gitolite's advanced features. While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step. The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses. This "rc" file is documented in [doc/gitolite.rc.mkd][rcdoc] so you should be able to make any changes you need quite easily, save it, and continue. This file also contains various settings that you can change to enable or disable some of gitolite's advanced features.
<a name="_Config_File_and_Access_Control_Rules_"></a> <a name="_Config_File_and_Access_Control_Rules_"></a>
@ -63,7 +63,8 @@ Once the install is done, you switch to the `gitolite-admin` repository (placed
keydir/sitaram.pub keydir/sitaram.pub
$ cat conf/gitolite.conf $ cat conf/gitolite.conf
#gitolite conf #gitolite conf
# please see conf/example.conf for details on syntax and features # please see doc/gitolite.conf.mkd for details on syntax and features
repo gitolite-admin repo gitolite-admin
RW+ = sitaram RW+ = sitaram
@ -73,7 +74,7 @@ Once the install is done, you switch to the `gitolite-admin` repository (placed
Notice that "sitaram" (the last argument in the `gl-easy-install` command you gave earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. Notice that "sitaram" (the last argument in the `gl-easy-install` command you gave earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
The config file syntax for gitolite is liberally documented in `conf/example.conf`, so we'll only mention some highlights here. The config file syntax for gitolite is documented in [doc/gitolite.conf.mkd][confdoc] so we'll only mention some highlights here.
You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn't even matter whether they are projects or users; that distinction is only made when you *use* the "macro". You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn't even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
@ -184,3 +185,6 @@ We'll round off this discussion with a sampling of other features, all of which,
**Gitweb support**: Gitolite supports gitweb in several ways. You can specify which repos are visible via gitweb. You can set the "owner" and "description" for gitweb from the gitolite config file. Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the "compiled" config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite. **Gitweb support**: Gitolite supports gitweb in several ways. You can specify which repos are visible via gitweb. You can set the "owner" and "description" for gitweb from the gitolite config file. Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the "compiled" config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite.
**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down. **Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.
[rcdoc]:http://sitaramc.github.com/gitolite/doc/gitolite.rc.html
[confdoc]:http://sitaramc.github.com/gitolite/doc/gitolite.conf.html

11
doc/wildcard-repositories.mkd
View file

@ -48,8 +48,8 @@ creating the repo. The examples below will make this clearer.
### rc file setting required ### rc file setting required
This feature requires that you set `$GL_WILDREPOS` to "1" in `~/.gitolite.rc` This feature requires that you set `$GL_WILDREPOS` to "1" in `~/.gitolite.rc`
on the server. Please search for that variable and see comments around it in on the server. Please search for that variable in `doc/gitolite.rc.mkd`
`conf/example.gitolite.rc` for more information on this. for more information on this.
<a name="_examples_of_wildcard_repos"></a> <a name="_examples_of_wildcard_repos"></a>
@ -156,7 +156,7 @@ metacharacters.
#### contrast with refexes #### contrast with refexes
Just for interest, note that this is in contrast to the refexes for the normal Just for interest, note that this is in contrast to the refexes for the normal
"branch" permissions, as described in `conf/example.conf` and elsewhere. "branch" permissions, as described in `doc/gitolite.conf.mkd` and elsewhere.
These "refexes" are only anchored at the start; a pattern like These "refexes" are only anchored at the start; a pattern like
`refs/heads/master` actually can match `refs/heads/master01/bar` as well, even `refs/heads/master` actually can match `refs/heads/master01/bar` as well, even
if no one will actually push such a branch! You can anchor both sides if you if no one will actually push such a branch! You can anchor both sides if you
@ -233,9 +233,8 @@ people, say by sending something like this to `setperms`:
INTERNS ashok INTERNS ashok
TESTERS ashok TESTERS ashok
You can enable do this by setting the `GL_WILDREPOS_PERM_CATS` variable in the You can enable this by setting the `GL_WILDREPOS_PERM_CATS` variable in the rc
rc file. The example rc file (`conf/example.gitolite.rc`) explains how to do file. The rc file documentation (`doc/gitolite.rc.mkd`) explains how.
this, with sample code.
<a name="_IMPORTANT_WARNING_ABOUT_THIS_FEATURE_"></a> <a name="_IMPORTANT_WARNING_ABOUT_THIS_FEATURE_"></a>

4
src/gl-compile-conf
View file

@ -532,8 +532,8 @@ for my $repo (@phy_repos) {
# - specifying a description also counts as enabling gitweb # - specifying a description also counts as enabling gitweb
# - description and owner are not specified for wildrepos; they're # - description and owner are not specified for wildrepos; they're
# specified for *actual* repos, even if the repo was created by a # specified for *actual* repos, even if the repo was created by a
# wild card spec and "C" permissions. If you see the # wild card spec and "C" permissions. If you see the docs for the
# conf/example.conf file, you will see that repo owner/desc don't go # gitolite.conf file, you will see that repo owner/desc don't go
# into the "repo foo" section; they're essentialy independent. # into the "repo foo" section; they're essentialy independent.
# Anyway, I believe it doesn't make sense to have all wild repos # Anyway, I believe it doesn't make sense to have all wild repos
# (for some pattern) to have the same description and owner. # (for some pattern) to have the same description and owner.

4
src/gl-easy-install
View file

@ -401,7 +401,7 @@ run_install() {
initial_conf_key() { initial_conf_key() {
echo "#gitolite conf echo "#gitolite conf
# please see conf/example.conf for details on syntax and features # please see doc/gitolite.conf.mkd for details on syntax and features
repo gitolite-admin repo gitolite-admin
RW+ = $admin_name RW+ = $admin_name
@ -630,7 +630,7 @@ created on the server.
ADDING USERS: copy their pubkey as keydir/<username>.pub, add it, commit and ADDING USERS: copy their pubkey as keydir/<username>.pub, add it, commit and
push. push.
CONFIG FILE FORMAT: see comments in conf/example.conf in the gitolite source. CONFIG FILE FORMAT: see doc/gitolite.conf.mkd
SSH MAGIC: Remember you (the admin) now have *two* keys to access the server SSH MAGIC: Remember you (the admin) now have *two* keys to access the server
hosting your gitolite setup -- one to get you a command line, and one to get hosting your gitolite setup -- one to get you a command line, and one to get