I am using Redmine Git hosting plugin [1] which relies on gitolite for
its repository management. After setting them both up properly, I tested
that they are working.
Now, on my server machine, I have the user redmine as admin for gitolite.
Using the same, I edited the conf/gitolite.conf file and added the following
to it:
repo @all
RW+ = admin @all
then I pushed the changes to the gitolite user. Testing the changes with
ssh git@myserver info
shows me that I had RW+ access on all projects/repos. Now that my test was
successful, I created a repository unrelated to redmine. A few commits later,
I think I should instead delete this repository. I do:
$ ssh git@myserver D unlock some-repo
FATAL: unknown git/gitolite command: 'D unlock some-repo'
$ ssh git@myserver D rm some-repo
FATAL: unknown git/gitolite command: 'D rm some-repo'
ok, so that failed. I can still delete the repo on server itself. So, on
the server:
1. Edit projects.list to remove some-repo from it
2. rm -rf repositories/some-repo
That worked. I now think that allowing RW+ to @all on all repos was pertty
bad, and edit the gitolite.conf again (on server, with redmine user's
account) and push the changes back to gitolite. So far so good. The
permissions are updated, the repository has been removed and we're happy.
But when I now change any configuration for a repo using redmine's
web-panel (such as adding a new developer to an existing repository) all the
changes get reset, the deleted repository is initialised with no history
and the `RW+ = @all` permissions are back in place... Looking at gitolite-admin repository's log:
$ git log --graph --oneline
* 0c73c10 update_repository : my/project/repo
* 9d789f9 [gitolite-rugged] Merged `origin/master` into `master`
|\
| * 2d203fc Deny RW+ acess to @all
|/
* e1a3e60 disable_readme_creation : Disable README file creation for repositories
It seems that `[gitolite-rugged]` commit is the one causing the commotion. Is there some way to overcome this hurdle.
[1]:
http://redmine-git-hosting.io/