diff --git a/doc/3-faq-tips-etc.mkd b/doc/3-faq-tips-etc.mkd index 7f47751..1fd56d9 100644 --- a/doc/3-faq-tips-etc.mkd +++ b/doc/3-faq-tips-etc.mkd @@ -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 diff --git a/doc/gitolite-without-ssh.mkd b/doc/gitolite-without-ssh.mkd index 4463363..7ab5dfb 100644 --- a/doc/gitolite-without-ssh.mkd +++ b/doc/gitolite-without-ssh.mkd @@ -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 diff --git a/doc/gitolite.rc.mkd b/doc/gitolite.rc.mkd index 180535c..de3ae15 100644 --- a/doc/gitolite.rc.mkd +++ b/doc/gitolite.rc.mkd @@ -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. + ### variables with an efficiency/performance impact diff --git a/doc/mirroring.mkd b/doc/mirroring.mkd index aed9620..94d3170 100644 --- a/doc/mirroring.mkd +++ b/doc/mirroring.mkd @@ -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.