Please take note of the following points:
If you're bringing existing repos into gitolite, please see [this][existing] first.
Gitolite expects all the directories and files it manages/uses to be owned by the [hosting user][nnc] and not have strange permissions and ownerships.
Gitolite does NOT like it if you fiddle with files and directories it cares about in any way except as directed in the documentation.
Gitolite cares about the following files and directories
~/.gitolite.rc ~/.gitolite ~/repositories/gitolite-admin.git
Also, in each repo, gitolite cares about
Gitolite depends on several system-installed packages: openssh, git, perl, sh being the main ones. They should all be configured sensibly and with most of the normal defaults. (For example, if your sshd config says the authorized keys file should be placed in some directory other than the default, expect trouble).
...ok that's the serious stuff done...
For the entertainment of the sensible majority, and as a way of thanking all of you, here are some examples of requests (demands in some cases) I have received over the last couple of years.
deleting environment variables copied from client session
demand: add code to delete certain environment variables at startup because "the openssh servers in the linux distribution that [he] use[s], are configured to copy
GIT_*variables to the remote session".
This is wrong on so many levels it's almost plonk-able!
Guy has an NTFS file system mounted on Linux. So... no symlinks (an NTFS file system on Windows works fine because msysgit/cygwin manage to simulate them. NTFS mounted on Linux won't do that!)
He wanted all the symlink stuff to be replaced by copies.
non-bare repos on the server
Some guy gave me a complicated spiel about git-svn not liking bare repos or whatever. I tuned off at the first mention of those 3 letters so I don't really know what the actual problem was.
But it doesn't matter. Even if someone (Ralf H) had not chipped in with a workable solution, I still would not do it. A server repo should be bare. Period.
incomplete ownership of
This guy had a repo-base directory where not all of the files were owned by the git user. As a result, some of the hooks did not get created. He claimed my code should detect OS-permissions issues while it's doing its stuff.
No. I refuse to have the code constantly look over its shoulder making sure fundamental assumptions are being met.
empty template directory
(See man git-init for what a template directory is).
The same guy with the environment variables had an empty template directory because he "does not like to have sample hooks in every repository". So naturally, the hooks directory does not get created when you run a
git init. He expects gitolite to compensate for it.
Granted, it's only a 1-line change. But again, this falls under "constantly looking over your shoulder to double check fundamental assumptions". Where does it end?