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

(minor) some minor doc fixes

Browse source
This commit is contained in:
Sitaram Chamarty 2011-06-14 20:19:14 +05:30
parent 5381dbb2da
commit 1f768a1763
4 changed files with 11 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -448,7 +448,9 @@ feature and tie it to gitolite. Configuration example can be found in
##### umask setting
Gitweb not able to read your repos? You can change the umask for newly
created repos to something more relaxed -- see the `~/.gitolite.rc` file
created repos to something more relaxed -- see the `REPO_UMASK` setting in the [`~/.gitolite.rc`][rc] file.
[rc]: http://sitaramc.github.com/gitolite/doc/gitolite.rc.html
<a name="_advanced_features"></a>

4
doc/gitolite-without-ssh.mkd
View file

@ -35,8 +35,8 @@ With that background, here's the truth about gitolite:
Yes, the default mode of using gitolite does use ssh keys, but all it's doing
is helping you **setup** ssh-based authentication **as a convenience to you**.
But nothing forces you to use it. The best example: there are no ssh keys
involved if you setup [smart http][sh] mode.
But nothing forces you to use it. The best example: gitolite does not setup
any keys or passwords if you install it in [smart http][sh] mode.
[sh]: http://sitaramc.github.com/gitolite/doc/http-backend.html

5
doc/gitolite.rc.mkd
View file

@ -60,6 +60,11 @@ things happen if you change them.
adjust permissions of files and directories that have already been
created.
**Note**: if you change this setting on a running gitolite install, you
*do* need to run a manual `chmod` on the server to fix up files already
created, since umask only affects the permissions on newly created files,
not existing ones.
<a name="_variables_with_an_efficiency_performance_impact"></a>
### variables with an efficiency/performance impact

2
doc/mirroring.mkd
View file

@ -114,7 +114,7 @@ slaves.
#### generate keypairs
Each server will be potentially logging on to one or more of the other
servers, so first generate keypairs for all of them (`ssh-keygen`) and copy
servers, so first generate keypairs on each of them (`ssh-keygen`) and copy
the `.pub` files to all other servers, named appropriately. So foo will have
bar.pub and baz.pub, etc.