Installed gitolite3 on debian using a key called git.pub
Lost the private half.
"Fixed" the problem with a new key called rsa_git.pub, this was manually inserted into .ssh/authorized_keys instead of redoing the install.
Stuff worked (for about 5 months) long enough to dispel any suspicious that it was all funky and rotten underneath.
Tried to update the admin repo to add a new repo - all hell broke loose.

$ git clone ssh://git@face.mechani.se/gitolite-admin.git admin_face Cloning into 'admin_face'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

“

When in doubt, run 'gitolite setup' anyway; it doesn't do any harm, though it may take a minute or so if you have more than a few thousand repos!

”

This is not in any way true. It is entirely possible that running setup on a live install will break that install. It is not a safe operation at all. Do not believe the lies: there is no cake. After using this to install the new key something really bad happened, it looks like this:

FATAL: R any gitolite-admin rsa_git DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

So at this point things look really bad as access to the admin interface has been lost. This can be confirmed by trying to ssh directly into the git user on the server which shows this:

PTY allocation request failed on channel 0 hello rsa_git, this is git@face running gitolite3 3.6.1-2 (Debian) on git 2.1.4 R W testing

A bit more googling shows that people then tend to panic and wipe their gitolite install and install from scratch to fix this. Instead I will now quote again from the gitolite3 docs:

First, have a poke around the git user directory (if you no longer have a way to do this, i.e. you do not have root on the box, then go ahead and panic, that's probably the right approach). .gitolite/logsis very interesting and lets you reconstruct what has happened. More importantly: .gitolite/confis where the bare contents of your admin repo get blasted into!

So fix .gitolite/conf/gitolite.conffirst to regain access (i.e. change the keynames on every repo). This will not do anything at all, so note the presence of a file called gitolite.conf-compiled.pm that is obviously a cache. Delete it. This still does not work but at least the error message changes to indicate it needs that file. Finally, just run:

Markdown syntax is based on RST: 
*italics* **bold** are inline styles. 
Paragraphs wrap

until blank lines separate. Other inline 
styles are :code:`x=y+z`, :shell:`ls` and 
:math:`x^n=y^n+z^n`. Links are 
`here `_ and blocks 
require blank lines

.. code::

  x <- f(y)
  // Until indent change

* Bullets are not indented
* Listed between blank lines

Markdown syntax is based on RST: italics bold are inline styles. Paragraphs wrap

until blank lines separate. Other inline styles are x=y+z lsand \$(x^n=y^n+z^n\$) Links are here and blocks require blank lines

x <- f(y) // Until indent change

Bullets are not indented
Listed between blank lines

Avoiding The Needless Multiplication Of Forms

A Quick Note On Unbreaking Gitolite

Some quick notes on de-fuck-ifying a gitolite3 installation

Symptoms

Solution

Comments