[RFC] Using sticky directories to control access to branches.

I had a thought this morning. I wanted to use file permissions to control access to push to a particular branch in a repository in order to implement some sort of per-branch policy. This assumes that there is a repository setup into which multiple users can push.

My goals were to be able to...

a) allow only one user (or possibly one group) access to modify a
   branch.  Do this on per-branch basis.
b) Freeze tags so that they *cannot* be accidentally updated by a push.

My plan to accomplish this was to set the sticky bit (chmod +t) on the refs/heads and refs/tags directories so that users couldn't bypass file-permissions by replacing the file with their own. Then grant write permission to the owner (or possibly a group) to allow updates to that branch.

I started testing this with git v0.99.9i and found that git push actually creates a new file and replaces the old branch file with the new one. The consequence for me is that when I set the sticky bit on the heads directory then all of the branches restrict access solely to the owner of the file since only the owner will be able to replace it. This precludes giving a group write access to the branch. It also precludes leaving most of the branches open to all users by default.

Now, git was probably designed to do this on purpose because it is the safest way to update a branch in an automic way. But, I wonder if there is another way. Maybe, git could make a temporary backup of the branch doing something like this:

% cp refs/heads/master{,.$randomstring} (on success, go ahead and edit refs/heads/master in place) (on success, remove refs/heads/master.$randomstring

Something like this could still be pretty safe but would allow per-branch access restrictions using unix file permissions.

Carl