Gitit as my personal wiki


I’ve wanted a personal wiki for a while now. The problem is there wasn’t any good software out there for it, or I couldn’t find it.

My favorite production wiki software is MediaWiki. You’ve seen it, and probably even heard about it: it runs Wikipedia, the fantastic Arch Linux Wiki, and a billion other great wiki websites out there. But it’s enterprise-grade wiki software, if you know what I mean. I’ve deployed it before with LDAP authentication. It runs on PHP. There’s a SQL backend. I don’t want that on my laptop.

MoinMoin is the runner-up in wiki software. Kernel Newbies uses this. So do Ubuntu and It’s written in Python, so I can hack at it without feeling like I’m playing with fire. But it uses Apache’s webserver and the ugly common wiki markup that anyone who’s worked with MediaWiki or similar are used to.

What I want

  1. Git backend
  2. Markdown files
  3. Web interface
  4. Interlinked documents

Give me these four things and I can sync my wiki across multiple computers, edit it in plaintext or online, and roll out pages into blog posts with minimal effort. That’s what I want. Even more ideally, I’d like to have Pandoc in the backend so I can write pages in whatever format I’d like.


Oh wait. I’ve seen this before.

Gitit does all that. It’s written in Haskell1 and pages only get updated when I commit them. I can write pages in LaTeX, markdown, or anything else supported by Pandoc. I get an API that I can mess with. The server backend is Happstack. Why haven’t I been using this?2


I could’ve installed it with cabal like a good Haskeller, but it was in the Debian repos and I don’t need it on multiple servers yet. So I did:

$ sudo aptitude install gitit
$ mkdir ~/wiki && cd ~/wiki
$ gitit

and I had a wiki.


The first thing I didn’t like was that Gitit doesn’t run in the background, and it didn’t run at launch. I stopped having a systemd user config (which I loved) when I moved to Debian, since even on sid the latest I can get is systemd 204. I’m not completely exactly sure what is going on under the hood with my systemd init in Debian, so I’m not about to compile 215 or something.

But I still want to daemonize this process. A quick Google search rescued me:

You can daemonize any executable in Unix by using nohup and the & operator:

nohup script args&

There’s a script provided that uses pidfiles to ensure it only ran once. I feel like this is something I’ll eventually hack into a set of personal scripts, so I whipped out the following:

# Grep for a process name, excluding grep from the output.
function psgrep() {
    ps aux | grep $1 | grep -v grep

# Spawn a daemonized script ($1) only if it is not already started.
# If $2 is provided, this will run the daemon in that folder.
function daemonize_script () {
    if [[ -z $(psgrep $1) ]]; then
        if [[ -n $2 ]]; then
            cd $2
        nohup $1 > /dev/null 2>&1 &
        if [[ -n $2 ]]; then
            cd $olddir

daemonize_script gitit ~/wiki

This starts gitit once, when I start my computer, and then not again.

Just using grep like this doesn’t work if you have other processes running that have that name in them. So this is pretty weak and not as useful as pidfiles, but it got the job done as a workaround.

Then I realized I didn’t want ~/wiki to have a bunch of gitit stuff in it - I just wanted the pages and Git repo. The repository is in there by default - but how to separate the Gitit data wasn’t obvious.

My first shot was just to move Gitit to ~/.gitit and symlink ~/.gitit/wikidata to ~/wiki, which worked when I ran it manually, but it broke my simple zsh script. To complicate things more, I also needed to start Gitit with a custom config file,3 which has to be passed as an argument like gitit -f my.conf. I could make this work with multiple arguments, but …

Adding a start_gitit script to my ~/bin folder solved this:

#!/usr/bin/env bash
gitit -f $HOME/.gitit/my.conf

So now I’m calling

daemonize_script ~/bin/start_gitit ~/.gitit

and that gets the job done. I’m looking forward to spending more time with my daemonizing scripts, since I know they’re worthless as-is, but eventually might prove a useful thing to have around.

Having a wiki

In my first couple of days with Gitit, I’ve started collecting useful bits of notes and categorizing them. It’s nice because Pandoc’s markdown (as opposed to, say, regular markdown) is powerful enough to give me everything I want for writing, and is overall simpler than org-mode.

I made a lot of edits to the Arch Wiki last year, so I know that they’re a format that I appreciate. Interlinking documents is an awesome feature.

As much as I love Org-mode, I’m still learning to cope with its complexity and it’s nowhere near as portable as having a markdown wiki in my home folder.

Moving forward

This is a new personal project for me, so there’s still a lot of goals. If it becomes an ongoing effort of mine (I hope so!), then I should do the following:

  1. Like Pandoc and Hakyll, which I use for this website.↩︎

  2. There was one feature it was missing when I tried it out last time. I can’t remember it anymore. It must not have mattered much.↩︎

  3. There isn’t a way to let anyone edit the wiki without a config file. I’m just hosting this locally for myself, so I have no need for a user account system and might eventually figure out a way to remove it.↩︎