I regret having to write this post, but apparently my suggestions shall be ignored along with those from anyone that isn’t the author. The author, Sitaram Chamarty, only takes patches to documentation and not the actual application. I find this attitude pretty sad indeed. No man is an island, especially not in the world of FOSS code.
There are two problems, that are related, that I had with gitolite. I was trying to get my dearly beloved girlfriend access to some repos on my server in California when I ran into the trouble that lead me to track down the cause. I had successfully set her up with an ssh key/config and git installation (she is a complete technophobe) all over the phone, gmail chat, and skype. We tried to clone our first repo, and it asked for a password, strange! I figured that I had done something wrong on her setup, somehow, remotely and setup a second account for myself on a friends home boxy that I have access to with dyndns (Thanks Dave!). However, after I replicated her config setup, when I tried to clone a repo, it failed in the same way. That’s odd, I thought, and hacked around with ssh until I proved that it was using the key as it should have been. Weird!
The only thing left to do was go digging on the server, so that is what I did. I quickly found that the authorizedkeys file had not been updated with Isabel’s key, nor my new test account. Hmmm. I then remembered that when setting up my symlink style repos, the subsequent gitolite admin repo pushes had resulted in errors, but upon fixing each error another appeared… I had given up fixing them because I found out that they seemed to do nothing and didn’t care. However, now it occurred to me that the fact they were failing early, and not continuing to try to update further repos possibly meant that it was failing completely and not ever adding the ssh keys to the auth file. I was right! Upon creating all the missing symlinks to the empty “gitolite-hooked” hook and pushing an empty line config file change in the gitolite admin repo, suddenly I could clone with the test account.
So, what’s wrong with this? Quite a few things, actually.
Firstly, when you have 100 symlink errors and it only reports the first one it finds in the file and then exits, you have to fix that first one, make a change to the config, commit, push, get the next message, fix that, and repeat, ONE HUNDRED TIMES. Not cool. It should treat each independent repo seperately and independently such that all errors are delivered at once, and can be dealt with at once.
Secondly, failing at the symlink stage and not trying to perform other independent operations such as add the authorisation keys is also flawed IMO. These tasks are unrelated and should not impact each other.
Thirdly, creating those symlinks silenced gitolite error messages, however, not correctly. My gitolite is now in an incosistent state without various hooks that it “needs” to do it’s thing. Pull/Push/Clone work, repo granularity permissions work fine, not sure what is not working, but it sure as hell does not matter to me, at all.
It turns out that gitolite checks for existance of this empty hook in order to determine whether or not it needs to create other real hooks/symlinks. OK, I guess that could work, BUT, not the way he does it. Currently he checks, if it’s not there, creates it, then tries to create the other links. If it fails to create the other links, but succeeds in creating the gitolite-hooked link, then the state is left inconsistent - he doesn’t clean up afterwards! That can happen if there are permissions for the git user to write to the directory, which allow it to create the empty and uniquely named symlink, however, there aren’t such permissions to allow it to overwrite the other hooks that are already present.
What is needed is one of the following three options:
- Create gitolite-hooked only after success in writing out the other hook links.
- Create gitolite-hooked first, but remove it if installation of other links fails.
- Forget the entire sentinel idea and just test for the stuff you actually want to be there rather than some indicator that can lie for a large variety of reasons…
At the VERY least, he should include something in the error message that makes it clear that the push did NOT complete the normal things that it needs to do to function. As it stands, it appears to the user that only one minor thing has gone wrong, not the entire system has fallen over because of a single symlink…
I was motivated to write this blog post because I tried to articulate myself to the author and had every idea and fix rejected out of hand simply on the basis of “I don’t want to”. The fact that the logic with which the hook test works is flawed doesn’t matter to him at all. It’s moments like this that I wonder about the quality of the rest of his work :-/
I commented to him that he seemed like a good guy:
> You seem like a good guy, so obviously you’re getting pounded with dumb
> requests resulting in your “i accept doc fixes, not code fixes” statement.
And this is the response that I received:
I only *seem* like a good guy, actually. You found out my
secret much, much, faster than most people; in fact many
people haven’t even found out yet. No idea why though :-)
I was stunned to say the least. Mostly because after reading the rest of his email in response to a carefully worded email of mine that I had spent half an hour or so on, I simply had to agree. I’ll save the expletives for the next driver that cuts me off, he’s not worth the breath.
Fred.