doc fixes related to conf and rc getting their own doc files
This commit is contained in:
Sitaram Chamarty
parent
81f39bd64c
commit
d2cef2d05e
|
|
@ -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.
|
||||
|
||||
* 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
|
||||
and give them permissions as required. The users names should be exactly
|
||||
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
|
||||
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:
|
||||
|
||||
git config section.key value # value may be an empty string
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ seem to hurt anything. [Update 2009-09-14; this has been fixed in git
|
|||
#### `@all` syntax for repos
|
||||
|
||||
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
|
||||
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
|
||||
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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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
|
||||
should not) have shell access to the server, then allowing him to set
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ That last command does produce a fair amount of output, which might be interesti
|
|||
|
||||
### 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>
|
||||
|
||||
|
|
@ -63,7 +63,8 @@ Once the install is done, you switch to the `gitolite-admin` repository (placed
|
|||
keydir/sitaram.pub
|
||||
$ cat 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
|
||||
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.
|
||||
|
||||
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".
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
**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
|
||||
|
|
|
|||
|
|
@ -48,8 +48,8 @@ creating the repo. The examples below will make this clearer.
|
|||
### rc file setting required
|
||||
|
||||
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
|
||||
`conf/example.gitolite.rc` for more information on this.
|
||||
on the server. Please search for that variable in `doc/gitolite.rc.mkd`
|
||||
for more information on this.
|
||||
|
||||
<a name="_examples_of_wildcard_repos"></a>
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ metacharacters.
|
|||
#### contrast with refexes
|
||||
|
||||
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
|
||||
`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
|
||||
|
|
@ -233,9 +233,8 @@ people, say by sending something like this to `setperms`:
|
|||
INTERNS ashok
|
||||
TESTERS ashok
|
||||
|
||||
You can enable do this by setting the `GL_WILDREPOS_PERM_CATS` variable in the
|
||||
rc file. The example rc file (`conf/example.gitolite.rc`) explains how to do
|
||||
this, with sample code.
|
||||
You can enable this by setting the `GL_WILDREPOS_PERM_CATS` variable in the rc
|
||||
file. The rc file documentation (`doc/gitolite.rc.mkd`) explains how.
|
||||
|
||||
<a name="_IMPORTANT_WARNING_ABOUT_THIS_FEATURE_"></a>
|
||||
|
||||
|
|
|
|||
|
|
@ -532,8 +532,8 @@ for my $repo (@phy_repos) {
|
|||
# - specifying a description also counts as enabling gitweb
|
||||
# - description and owner are not specified for wildrepos; they're
|
||||
# specified for *actual* repos, even if the repo was created by a
|
||||
# wild card spec and "C" permissions. If you see the
|
||||
# conf/example.conf file, you will see that repo owner/desc don't go
|
||||
# wild card spec and "C" permissions. If you see the docs for the
|
||||
# gitolite.conf file, you will see that repo owner/desc don't go
|
||||
# into the "repo foo" section; they're essentialy independent.
|
||||
# Anyway, I believe it doesn't make sense to have all wild repos
|
||||
# (for some pattern) to have the same description and owner.
|
||||
|
|
|
|||
|
|
@ -401,7 +401,7 @@ run_install() {
|
|||
|
||||
initial_conf_key() {
|
||||
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
|
||||
RW+ = $admin_name
|
||||
|
|
@ -630,7 +630,7 @@ created on the server.
|
|||
ADDING USERS: copy their pubkey as keydir/<username>.pub, add it, commit and
|
||||
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
|
||||
hosting your gitolite setup -- one to get you a command line, and one to get
|
||||
|
|
|
|||
Loading…
Reference in a new issue