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.