diff --git a/posts/gitolite_lessons.mdwn b/posts/gitolite_lessons.mdwn
new file mode 100644
index 0000000..ce0992b
--- /dev/null
+++ b/posts/gitolite_lessons.mdwn
@@ -0,0 +1,71 @@
+A while back I found out how
+[gitolite](https://github.com/sitaramc/gitolite) handles multiple
+users, by reading the manual, whilst trying to figure out how to
+enable SSH agent forwarding so I can semi-automatically mirror some
+repositories to, for instance, [github](http://github.com).  I came to
+the conclusion that I had to override the *gitolite* settings and add
+an extra line to my server's `authorized_keys` file.  This seemed to
+work well.
+
+Though apparently it didn't...  I had noticed that I couldn't set any
+options through the `gitolite.conf`'s `config` commands, but I thought
+this had something to do with not enabling the right settings to be
+added.  I was wrong about that...
+
+I looked at my `.gitolite.rc` on my server and saw that I had already
+set `GIT_CONFIG_KEYS` to `'.*'`, so everything was allowed.  I also
+tested adding random config values to git locally, like
+`test.something`, which also worked; so it was neither git nor
+*gitolite* that was causing the trouble.
+
+I also noticed today that when I pushed changes to *gitolite*, at least
+to the `gitolite-admin` repo, that it was complaining about not being
+able to fingerprint some file in `/tmp/`.  At that time I didn't think
+the issues were connected, since I hadn't changed much lately and
+pushing/pulling to my repositories seemed to go fine, apart from the
+config values.
+
+After some testing I noticed that I couldn't use any config values,
+not even the `gitweb.owner` setting which I was sure would work, since
+I'd used that for every repo, but trying to reset them now didn't work
+either.  So I started looking on the server.  It showed me the same
+error as when I'd push to the `gitolite-admin` repo *plus* a message
+about the first line of something being too long, showing the
+beginnings of a line in `authorized_keys`.
+
+After a lot of looking around, testing, screwing up my entire setup
+**and** looking at the *gitolite* source on *github*, I think I
+figured out what it's doing.  Now, I don't know any perl, but is
+seemed to me that it splits up the `authorized_keys` file, checking
+the validity of each line in it, except for the ones it put there.
+This is where it was failing, since it would assume each line was just
+a public key and could be verified by placing it in a temporary file
+and fingerprinting that with `ssh-keygen -l -f`, and I had the
+`command="..."` part in there as well, to override *gitolite*'s own
+settings to enable agent forwarding.  So now I know why it was
+complaining and why it was *always* about line 1, even when I put my
+key on the last line in `authorized_keys`, but removing it would mean
+no ssh agent forwarding.
+
+So I started looking at the *gitolite* source code again, trying to
+figure out where those settings of `no-X11-forwarding`,
+`no-agent-forwarding`, etc. were coming from and after a little while
+I found it.  Here I also saw that it was actually looking for the
+`AUTH_OPTIONS` rc setting.  I don't remember reading anything about
+this option, but then I'm still learning to navigate the *gitolite*
+manual.  Setting that to whatever was in my `authorized_keys` file,
+but leaving out the `no-agent-forwarding`, fixed this latest problem.
+
+So, now I've got my ssh agent forwarding **and** I can set any git
+config variable I want, which paves the way for writing a hook that
+will try to mirror a repository after receiving an update.  This was
+certainly an interesting experience, and looking at some perl code was
+fun.
+
+**Oh**, and I've also updated my *gitolite* installation, which now
+includes a `update-description-file` `post-compile` trigger, which
+takes the value from `gitweb.description` and puts it in the
+`description` file, so programs like
+[cgit](http://hjemli.net/git/cgit/) can use it too.
+
+[[!tag git gitolite configuration ssh]]