-## Configuration
-
-### Ikiwiki working directory
-
-* Configure a cgi wrapper as usual, but configure the git wrapper to
- be written to the post-commit hook of the bare root repository. Set
- in the configuration:
-
- gitorigin_branch=> "origin",
- ## git post-commit wrapper
- wrapper => "/path/to/bare/repo/.git/hooks/post-commit",
-
-
-
-### Working clones (Clone 1 .. N in the image)
-
-These are repositories usually setup to avoid permission problems with
-the working directory used by ikiwiki itself. They also represent the
-most convenient way to add content to the wiki on a different machine
-(that is, not the machine the wiki is published on) which is more
-convenient.
-
-The use case for these clones is this: If you want to edit your wiki
-on your development box, or on your laptop, you usually set up a clone
-as above. But very often, you also want to test what the changes look
-like, locally, before pushing it to the root repository and publishing
-the wiki for the world to see.
-
-In order to do this, you should another setup file and setup a private
-ikiwiki on the local machine (your laptop, for instance) where you do
-most of your editing. You will also need to set up a webserver, and
-install ikiwiki on this machine. Only when you are happy with any
-changes do you push them to the root repository.
-
-Here are some things to be aware of when configuring ikiwiki on the
-local machine:
-
-* By default, ikiwiki pulls and pushes from `origin`. This is not
- ideal for the working clones on the local machine, since you might
- go through several iterations of a page before pushing to the bare
- root of the repository tree and publishing it on your public
- wiki. In the configuration, set:
-
- gitorigin_branch => "",
- ## git post-commit wrapper
- wrapper => "/working/dir/.git/hooks/post-commit",
-
- Then just committing should refresh the private ikiwiki on the local
- host.
-
-* You can optionally enable to the [[plugins/mirrorlist]] plugin,
- and configure it so that each page links to the corresponding page on the
- server.
-
-Now just run `ikiwiki -setup wiki.setup -getctime` and you should be
-good to go. (You only need the slow `-getctime` option the first time you
-run setup.)
-
-Use standard git commands to handle pulling from and pushing to the server.
-
-Note: Currently, after pulling changes, you will need to manually update
-the wiki, with a command such as `ikiwiki -setup wiki.setup -refresh`. This
-is because git 1.5.4 doesn't have a hook that is run locally after pulling
-changes. Newer versions of git will have a `post-merge` hook that should
-work for this purpose.
+## git repository with untrusted committers
+
+By default, anyone who can commit to the git repository can modify any file
+on the wiki however they like. A `pre-receive` hook can be set up to limit
+incoming commits from untrusted users. Then the same limits that are placed
+on edits via the web will be in effect for commits to git for the users.
+They will not be allowed to edit locked pages, they will only be able to
+delete pages that the [[plugins/remove]] configuration allows them to
+remove, and they will only be allowed to add non-page attachments that the
+[[plugins/attachment]] configuration allows.
+
+To enable this, you need to set up the git repository to have multiple
+committers. Trusted committers, including the user that ikiwiki runs as,
+will not have their commits checked by the `pre-receive` hook. Untrusted
+committers will have their commits checked. The configuration settings to
+enable are `git_test_receive_wrapper`, which enables generation of a
+`pre-receive` hook, and `untrusted_committers`, which is a list of
+usernames of the untrusted committers.
+
+Note that when the `pre-receive` hook is checking incoming changes, it
+ignores the git authorship information, and uses the username of the unix
+user who made the commit. Then tests including the `locked_pages`
+[[ikiwiki/PageSpec]]
+are checked to see if that user can edit the pages in the commit.
+
+You can even set up an [[anonymous_user|tips/untrusted_git_push]], to allow
+anyone to push changes in via git rather than using the web interface.
+
+## Optionally using a local wiki to preview changes
+
+When working on your wiki,
+it is common (but optional) practice to preview your changes using a
+private wiki on the local host before publishing the updates by
+sending it to the root repository. If you do want to setup a private
+wiki, you will have to have another setup file and and an ikiwiki
+installation on your local machine. You will need all the packages
+this implies -- a web server, git, ikiwiki, etc. However, there is a
+_caveat_: by default, ikiwiki pulls and pushes from `origin`. This is
+not ideal for the working clones on the local machine, since you might
+go through several iterations of a page before pushing to the bare
+root of the repository tree (and thus publishing it on your public wiki).
+You do not want the action of refreshing the local wiki in order to
+review your work to accidentally publish the
+contents before you are ready. In order to prevent the git push that
+is the normal behaviour of ikiwiki, set the configuration of the local wiki:
+
+ gitorigin_branch => "",
+ ## git post-commit wrapper
+ git_wrapper => "/working/dir/.git/hooks/post-commit",
+
+Then just committing should refresh the private ikiwiki on the local
+host. Now just run `ikiwiki --setup localwiki.setup --gettime` and
+you should be good to go. (You only need the slow `--gettime` option
+the first time you run setup.) Use standard git commands to handle
+pulling from and pushing to the server. **Note**: After
+pulling changes from the bare root repository, you will need to
+manually update the local wiki, with a command such as `ikiwiki
+--setup localwiki.setup --refresh`. You could use git's `post-merge` hook
+to automate that command.
+
+## Using ikiwiki with Gerrit
+
+[Gerrit Code Review](https://code.google.com/p/gerrit/) manages a set of Git
+repositories and provides a web interface to review and merge commits. You can
+configure ikiwiki to work with a Gerrit-managed repository, allowing you to
+review and merge commits to your wiki.
+
+First, create your initial wiki repository with Gerrit. On the server, as the
+user that will own the wiki, clone that repository to create a working
+directory for ikiwiki, such as /srv/wiki/ikiwiki-checkout. Create a setup file
+and target directory as usual, referencing that working directory path, and
+creating a post-update hook in Gerrit's repository. You'll need to set
+appropriate permissions on the hook directory for the repository so that the
+user running ikiwiki can compile and install the post-update hook. Also note
+that you must disable web editing by disabling the editpage plugin, and you
+must not enable any other plugin that commits to the repository, since ikiwiki
+will not have permission to push to the repository. (Allowing web edits to
+have such permission would bypass Gerrit's code review, defeating the purpose.)
+
+Gerrit does not run per-repository hooks, such as the post-update hook ikiwiki
+installs to update the wiki after pushes. However, Gerrit has site-wide hooks,
+including a ref-updated hook that runs whenever a ref changes. You can use
+that hook to trigger ikiwiki's post-update hook. The following script,
+installed as Gerrit's ref-updated hook, will run the post-update hook on any
+repository that has a "gerrit-run-post-update-hook" file in it:
+
+ #!/bin/sh
+ if [ -e "$GIT_DIR/gerrit-run-post-update-hook" ] ; then
+ exec "$GIT_DIR/hooks/post-update"
+ fi
+
+Then just create gerrit-run-post-update-hook in the wiki repository, run
+ikiwiki --setup on the setup file, add your wiki to /etc/ikiwiki/wikilist, and
+start reviewing and committing wiki changes via Gerrit.