A wiki using HAppS, pandoc, and git

Open issues
Closed issues
Last commit
10 months ago
Total releases
Total commits
Open PRs
Closed PRs
Repo URL
Offers premium version?


Gitit is a wiki program written in Haskell. It uses Happstack for the web server and pandoc for markup processing. Pages and uploaded files are stored in a git, darcs, or mercurial repository and may be modified either by using the VCS's command-line tools or through the wiki's web interface. By default, pandoc's extended version of markdown is used as a markup language, but reStructuredText, LaTeX, HTML, DocBook, or Emacs Org-mode markup can also be used. Gitit can be configured to display TeX math (using texmath) and highlighted source code (using highlighting-kate).

Other features include

  • plugins: dynamically loaded page transformations written in Haskell (see "Network.Gitit.Interface")

  • categories

  • TeX math

  • syntax highlighting of source code files and code snippets (using highlighting-kate)

  • caching

  • Atom feeds (site-wide and per-page)

  • a library, "Network.Gitit", that makes it simple to include a gitit wiki in any happstack application

Getting started Compiling and installing gitit

The most reliable way to install gitit from source is to get the stack tool. Then clone the gitit repository and use stack to install:

git clone
cd gitit
stack install

Alternatively, instead of using stack, you can get the Haskell Platform and do the following:

cabal update
cabal install gitit

This will install the latest released version of gitit. To install a version of gitit checked out from the repository, change to the gitit directory and type:

cabal install

The cabal tool will automatically install all of the required haskell libraries. If all goes well, by the end of this process, the latest release of gitit will be installed in your local .cabal directory. You can check this by trying:

gitit --version

If that doesn't work, check to see that gitit is in your local cabal-install executable directory (usually ~/.cabal/bin). And make sure ~/.cabal/bin is in your system path.

Running gitit

To run gitit, you'll need git in your system path. (Or darcs or hg, if you're using darcs or mercurial to store the wiki data.)

Gitit assumes that the page files (stored in the git repository) are encoded as UTF-8. Even page names may be UTF-8 if the file system supports this. So you should make sure that you are using a UTF-8 locale when running gitit. (To check this, type locale.)

Switch to the directory where you want to run gitit. This should be a directory where you have write access, since three directories, static, templates, and wikidata, and two files, gitit-users and gitit.log, will be created here. To start gitit, just type:


If all goes well, gitit will do the following:

  1. Create a git repository, wikidata, and add a default front page.
  2. Create a static directory containing files to be treated as static files by gitit.
  3. Create a templates directory containing HStringTemplate templates for wiki pages.
  4. Start a web server on port 5001.

Check that it worked: open a web browser and go to http://localhost:5001.

You can control the port that gitit runs on using the -p option: gitit -p 4000 will start gitit on port 4000. Additional runtime options are described by gitit -h.

Using gitit Wiki links and formatting

For instructions on editing pages and creating links, see the "Help" page.

Gitit interprets links with empty URLs as wikilinks. Thus, in markdown pages, [Front Page]() creates an internal wikilink to the page Front Page. In reStructuredText pages, `Front Page <>`_ has the same effect.

If you want to link to a directory listing for a subdirectory, use a trailing slash: [foo/bar/]() creates a link to the directory for foo/bar.

Page metadata

Pages may optionally begin with a metadata block. Here is an example:

format: latex+lhs
categories: haskell math
toc: no
title: Haskell and
  Category Theory

\section{Why Category Theory?}

The metadata block consists of a list of key-value pairs, each on a separate line. If needed, the value can be continued on one or more additional line, which must begin with a space. (This is illustrated by the "title" example above.) The metadata block must begin with a line --- and end with a line ... optionally followed by one or more blank lines. (The metadata block is a valid YAML document, though not all YAML documents will be valid metadata blocks.)

Currently the following keys are supported:

format : Overrides the default page type as specified in the configuration file. Possible values are markdown, rst, latex, html, markdown+lhs, rst+lhs, latex+lhs. (Capitalization is ignored, so you can also use LaTeX, HTML, etc.) The +lhs variants indicate that the page is to be interpreted as literate Haskell. If this field is missing, the default page type will be used.

categories : A space or comma separated list of categories to which the page belongs.

toc : Overrides default setting for table-of-contents in the configuration file. Values can be yes, no, true, or false (capitalization is ignored).

title : By default the displayed page title is the page name. This metadata element overrides that default.

Highlighted source code

If gitit was compiled against a version of pandoc that has highlighting support (see above), you can get highlighted source code by using delimited code blocks:

~~~ {.haskell .numberLines}
qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++
               qsort (filter (>= x) xs) 

<p>To see what languages your pandoc was compiled to highlight:</p>
 <pre><code>pandoc -v
 Configuring and customizing gitit 
 Configuration options 
<p>Use the option <code>-f [filename]</code> to specify a configuration file:</p>
 <pre><code>gitit -f my.conf
<p>The configuration can be split between several files:</p>
 <pre><code>gitit -f my.conf -f additional.conf
<p>One use case is to keep sensible part of the configuration outside of a SCM
(oauth client secret for example).</p>
<p>If this option is not used, gitit will use a default configuration.
To get a copy of the default configuration file, which you
can customize, just type:</p>
 <pre><code>gitit --print-default-config &gt; my.conf
<p>The default configuration file is documented with comments throughout.</p>
 The <code>static</code> directory 
<p>On receiving a request, gitit always looks first in the <code>static</code>
directory (or in whatever directory is specified for <code>static-dir</code> in
the configuration file). If a file corresponding to the request is
found there, it is served immediately. If the file is not found in
<code>static</code>, gitit next looks in the <code>static</code> subdirectory of gitit's data
file (<code>$CABALDIR/share/gitit-x.y.z/data</code>). This is where default css,
images, and javascripts are stored. If the file is not found there
either, gitit treats the request as a request for a wiki page or wiki
<p>So, you can throw anything you want to be served statically (for
example, a <code>robots.txt</code> file or <code>favicon.ico</code>) in the <code>static</code>
directory. You can override any of gitit's default css, javascript, or
image files by putting a file with the same relative path in <code>static</code>.
Note that gitit has a default <code>robots.txt</code> file that excludes all
URLs beginning with <code>/_</code>.</p>
<p>Note:  if you set <code>static-dir</code> to be a subdirectory of <code>repository-path</code>,
and then add the files in the static directory to your repository, you
can ensure that others who clone your wiki repository get these files
as well.  It will not be possible to modify these files using the web
interface, but they will be modifiable via git.</p>
 Using a VCS other than git 
<p>By default, gitit will store wiki pages in a git repository in the
<code>wikidata</code> directory.  If you'd prefer to use darcs instead of git,
you need to add the following field to the configuration file:</p>
 <pre><code>repository-type: Darcs
<p>If you'd prefer to use mercurial, add:</p>
 <pre><code>repository-type: Mercurial
<p>This program may be called "darcsit" instead of "gitit" when a darcs
backend is used.</p>
<p>Note:  we recommend that you use gitit/darcsit with darcs version
2.3.0 or greater.  If you must use an older version of darcs, then
you need to compile the filestore library without the (default)
maxcount flag, before (re)installing gitit:</p>
 <pre><code>cabal install --reinstall filestore -f-maxcount
cabal install --reinstall gitit
<p>Otherwise you will get an error when you attempt to access your
 Changing the theme 
<p>To change the look of the wiki, you can modify <code>custom.css</code> in
<p>To change the look of printed pages, copy gitit's default <code>print.css</code>
to <code>static/css</code> and modify it.</p>
<p>The logo picture can be changed by copying a new PNG file to
<code>static/img/logo.png</code>. The default logo is 138x155 pixels.</p>
<p>To change the footer, modify <code>templates/</code>.</p>
<p>For more radical changes, you can override any of the default
templates in <code>$CABALDIR/share/gitit-x.y.z/data/templates</code> by copying
the file into <code>templates</code>, modifying it, and restarting gitit. The
<code></code> template is the master template; it includes the others.
Interpolated variables are surrounded by <code>$</code>s, so <code>literal $</code> must
be backslash-escaped.</p>
 Adding support for math 
<p>To write math on a markdown-formatted wiki page, just enclose it
in dollar signs, as in LaTeX:</p>
 <pre><code>Here is a formula:  $\frac{1}{\sqrt{c^2}}$
<p>You can write display math by enclosing it in double dollar signs:</p>
<p>Gitit can display TeX math in three different ways, depending on the
setting of <code>math</code> in the configuration file:</p>
<p><code>mathjax</code> (default): Math will be rendered using the <a href="" rel="nofollow">MathJax</a> javascript.</p>
<p><code>mathml</code>: Math will be converted to MathML using
<a href="" rel="nofollow">texmath</a>. This method works with IE+mathplayer, Firefox, and
Opera, but not Safari.</p>
<p><code>raw</code>: Math will be rendered as raw LaTeX codes.</p>
 Restricting access 
<p>If you want to limit account creation on your wiki, the easiest way to do this
is to provide an <code>access-question</code> in your configuration file. (See the commented
default configuration file.)  Nobody will be able to create an account without
knowing the answer to the access question.</p>
<p>Another approach is to use HTTP authentication. (See the config file comments on
 Authentication through github 
<p>If you want to authenticate the user from github through oauth2, you need to
register your app with github to obtain a OAuth client secret and add the
following section to your configuration file:</p>
oauthclientid: 01239456789abcdef012
oauthclientsecret: 01239456789abcdef01239456789abcdef012394
oauthcallback: http://mysite/_githubCallback
## Uncomment if you are checking membership against an organization and change
## gitit-testorg to this organization:
# github-org: gitit-testorg
<p>The github authentication uses the scope <code>user:email</code>. This way, gitit gets the
email of the user, and the commit can be assigned to the right author if the
wikidata repository is pushed to github. Additionally, it uses <code>read:org</code> if you
uses the option <code>github-org</code> to check membership against an organization.</p>
<p>To push your repository to gitub after each commit, you can add the file
<code>post-commit</code> with the content below in the .git/hooks directory of your
wikidata repository.</p>
git push origin master 2&gt;&gt; logit
<p>Plugins are small Haskell programs that transform a wiki page after it
has been converted from Markdown or another source format. See the example
plugins in the <code>plugins</code> directory. To enable a plugin, include the path to the
plugin (or its module name) in the <code>plugins</code> field of the configuration file.
(If the plugin name starts with <code>Network.Gitit.Plugin.</code>, gitit will assume that
the plugin is an installed module and will not look for a source file.)</p>
<p>Plugin support is enabled by default. However, plugin support makes
the gitit executable considerably larger and more memory-hungry.
If you don't need plugins, you may want to compile gitit without plugin
support.  To do this, unset the <code>plugins</code> Cabal flag:</p>
 <pre><code>cabal install --reinstall gitit -f-plugins
<p>Note also that if you compile gitit for executable profiling, attempts
to load plugins will result in "internal error: PAP object entered!"</p>
 Accessing the wiki through git 
<p>All the pages and uploaded files are stored in a git repository. By
default, this lives in the <code>wikidata</code> directory (though this can be
changed through configuration options). So you can interact with the
wiki using git command line tools:</p>
 <pre><code>git clone ssh://
cd wikidata
vim Front\  # edit the page
git commit -m "Added message about wiki etiquette" Front\
git push
<p>If you now look at the Front Page on the wiki, you should see your changes
reflected there.  Note that the pages all have the extension <code>.page</code>.</p>
<p>If you are using the darcs or mercurial backend, the commands will
be slightly different.  See the documentation for your VCS for
<p>By default, gitit does not cache content.  If your wiki receives a lot of
traffic or contains pages that are slow to render, you may want to activate
caching.  To do this, set the configuration option <code>use-cache</code> to <code>yes</code>.
By default, rendered pages, and highlighted source files
will be cached in the <code>cache</code> directory. (Another directory can be
specified by setting the <code>cache-dir</code> configuration option.)</p>
<p>Cached pages are updated when pages are modified using the web
interface. They are not updated when pages are modified directly through
git or darcs. However, the cache can be refreshed manually by pressing
Ctrl-R when viewing a page, or by sending an HTTP GET or POST request to
<code>/_expire/path/to/page</code>, where <code>path/to/page</code> is the name of the page to
be expired.</p>
<p>Users who frequently update pages using git or darcs may wish to add a
hook to the repository that makes the appropriate HTTP request to expire
pages when they are updated. To facilitate such hooks, the gitit cabal
package includes an executable <code>expireGititCache</code>. Assuming you are
running gitit at port 5001 on localhost, and the environment variable
<code>CHANGED_FILES</code> contains a list of the files that have changed, you can
expire their cached versions using</p>
 <pre><code>expireGititCache http://localhost:5001 $CHANGED_FILES
<p>Or you can specify the files directly:</p>
 <pre><code>expireGititCache http://localhost:5001 "Front" foo/bar/baz.c
<p>This program will return a success status (0) if the page has been
successfully expired (or if it was never cached in the first place),
and a failure status (&gt; 0) otherwise.</p>
<p>The cache is persistent through restarts of gitit.  To expire all cached
pages, simply remove the <code>cache</code> directory.</p>
<p>By default, GHC's runtime will repeatedly attempt to collect garbage
when an executable like Gitit is idle. This means that gitit will, after
the first page request, never use 0% CPU time and sleep, but will use
~1%. This can be bad for battery life, among other things.</p>
<p>To fix this, one can disable the idle-time GC with the runtime flag
 <pre><code>gitit -f my.conf +RTS -I0 -RTS
<p>To enable RTS, cabal needs to pass the compile flag <code>-rtsopts</code> to GHC while installing.</p>
 <pre><code>cabal install --reinstall gitit --ghc-options="-rtsopts"
 Using gitit with apache 
<p>Most users who run a public-facing gitit will want gitit to appear
at a nice URL like <code></code> or
<code></code> rather than <code></code>.
This can be achieved using apache's <code>mod_proxy</code>.</p>
 Proxying to <code></code>

<p>Set up your DNS so that <code></code> maps to
your server's IP address. Make sure that the <code>mod_proxy</code>, <code>mod_proxy_http</code> and <code>mod_rewrite</code> modules are
loaded, and set up a virtual host with the following configuration:</p>
 <pre><code>&lt;VirtualHost *&gt;
    DocumentRoot /var/www/
    RewriteEngine On
    ProxyPreserveHost On
    ProxyRequests Off

    &lt;Proxy *&gt;
       Order deny,allow
       Allow from all

    ProxyPassReverse /
    RewriteRule ^(.*)$1 [P]

    ErrorLog /var/log/apache2/error.log
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature On

<p>Reload your apache configuration and you should be all set.</p>
 Using nginx to achieve the same 
<p>Drop a file called <code></code> into <code>/etc/nginx/conf.d</code>
(or where ever your distribution puts it).</p>
 <pre><code>server {
    listen 80;
    location / {
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_redirect off;
    access_log /var/log/nginx/ main;
<p>Reload your nginx config and you should be all set.</p>
 Proxying to <code></code>

<p>Make sure the <code>mod_proxy</code>, <code>mod_headers</code>, <code>mod_proxy_http</code>,
and <code>mod_proxy_html</code> modules are loaded. <code>mod_proxy_html</code>
is an external module, which can be obtained [here]
(<a href="" rel="nofollow"></a>). It rewrites URLs that
occur in web pages. Here we will use it to rewrite gitit's links so that
they all begin with <code>/wiki/</code>.</p>
<p>First, tell gitit not to compress pages, since <code>mod_proxy_html</code> needs
uncompressed pages to parse. You can do this by setting the gitit
configuration option</p>
 <pre><code>compress-responses: no
<p>Second, modify the link in the <code>reset-password-message</code> in the
configuration file:  instead of</p>
<p>set it to</p>
<p>Restart gitit.</p>
<p>Now add the following lines to the apache configuration file for the
<code></code> server:</p>
 <pre><code># These commands will proxy /wiki/ to port 5001

ProxyRequests Off

&lt;Proxy *&gt;
  Order deny,allow
  Allow from all

ProxyPass /wiki/

&lt;Location /wiki/&gt;
  SetOutputFilter  proxy-html
  ProxyPassReverse /
  ProxyHTMLURLMap  /   /wiki/
  ProxyHTMLDocType "&lt;!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' ''&gt;" XHTML
  RequestHeader unset Accept-Encoding
<p>Reload your apache configuration and you should be set.</p>
<p>For further information on the use of <code>mod_proxy_http</code> to rewrite URLs,
see the <a href="" rel="nofollow"><code>mod_proxy_html</code> guide</a>.</p>
 Using gitit as a library 
<p>By importing the module <code>Network.Gitit</code>, you can include a gitit wiki
(or several of them) in another happstack application. There are some
simple examples in the haddock documentation for <code>Network.Gitit</code>.</p>
 Reporting bugs 
<p>Bugs may be reported (and feature requests filed) at
<a href="" rel="nofollow"></a>.</p>
<p>There is a mailing list for users and developers at
<a href="" rel="nofollow"></a>.</p>
<p>A number of people have contributed patches:</p>
<li>Gwern Branwen helped to optimize gitit and wrote the
InterwikiPlugin. He also helped with the Feed module.</li>
<li>Simon Michael contributed the patch adding RST support.</li>
<li>Henry Laxen added support for password resets and helped with
the apache proxy instructions.</li>
<li>Anton van Straaten made the process of page generation
more modular by adding Gitit.ContentTransformer.</li>
<li>Robin Green helped improve the plugin API and interface, and
fixed a security problem with the reset password code.</li>
<li>Thomas Hartman helped improve the index page, making directory
browsing persistent, and fixed a bug in template recompilation.</li>
<li>Justin Bogner improved the appearance of the preview button.</li>
<li>Kohei Ozaki contributed the ImgTexPlugin.</li>
<li>Michael Terepeta improved validation of change descriptions.</li>
<li>mightybyte suggested making gitit available as a library,
and contributed a patch to ifLoggedIn that was needed to
make gitit usable with a custom authentication scheme.</li>
<p>I am especially grateful to the darcs team for using darcsit for
their public-facing wiki.  This has helped immensely in identifying
issues and improving performance.</p>
<p>Gitit's default visual layout is shamelessly borrowed from Wikipedia.
The stylesheets are influenced by Wikipedia's stylesheets and by the
bluetrip CSS framework (see BLUETRIP-LICENSE). Some of the icons in
<code>img/icons</code> come from bluetrip as well.</p>

Alternative Projects
No projects found

Subscribe to Open Source Businees Newsletter

Twice a month we will interview people behind open source businesses. We will talk about how they are building a business on top of open source projects.

We'll never share your email with anyone else.