Gitosis by itself does not have a remove function because of the way it is managed through git commits. If you remove the repository from the gitosis.conf and commit the change then the repository is no longer accessible. You can re-enable it later or you can eventually log into the server and remove the file from the gitosis repositories/ directory.
I cloned my gitosis-admin.git repository and added the following then committed:
[group gitosis-admin]
writable = gitosis-admin test1
members = jbouse
I then went to my home directory and performed the following:
mkdir test1
cd test1
git init
git remote add origin git@server:test1.git
echo "Testing" > test.txt
git add test.txt
git commit -m 'First commit'
git push origin master:refs/heads/master
This should successfully push to the server and then I wiped the test1 directory away and clone it from gitosis:
git clone git@server:test1.git
cd test1
echo "Test worked" > test.txt
git add test.txt
git commit -m 'Second commit'
git push
This should also push successfully as well so I then remove the test1 line from the gitosis.conf config and commit the change... I then try the following:
cd test1
echo "Final test" > test.txt
git add test.txt
git commit -m 'Third commit'
git push
Unlike the previous two pushes this one fails with the following error message:
ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly
The error is because gitosis does not have anything configured for the test1 repository now. If you attempt to clone the repository again you will receive the same error.
Best Answer
Permissions are a pest.
Basically, you need to make sure that all of those developers can write to everything in the git repo.
Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.
The Standard Solution
If you put all the developers in a specially-created group, you can, in principle, just do:
Then change the
umaskfor the users to002, so that new files get created with group-writable permissions.The problems with this are legion; if you’re on a distro that assumes a
umaskof022(such as having a commonusersgroup that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you getrootaccess and fix it up (i.e., re-running the above commands).The New-Wave Solution
A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).
So once again, create your group, then run:
This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).
Hope that gets you on your way.