Intro

The recurring problem is that we run a shared development server in which there may be several people working on one project. I have each of them follow our Git protocal so that they make a branch named descriptively for each issue they are working on. Enters the problem: when one user switched to a branch, even later switching back to Master/Main, the next user would have permissions set blocking them because the git head or index was now owned by the previous user. This would not normally be a problem because we use proper user groups to share files – except that the file permissions disallowed anyone but the user from working with the git files, and those permissions persisted. This is an old, known issue, even addressed by git itself having a --shared option. The trouble is, that option is meant to be used only when creating a new repo, and that is not often the case for us. The trick was to change the git config file to have the same parameters as --shared creates, and to apply sticky permissions to existing files.

Solution by editing git configuration file and sticky group permissions an the folders

There were a couple of helpful Stack Overflow¹ answers on this topic, from which I’ve extracted the answers here.

The git configuration file needs to have added core.sharedRepository=2 and receive.denyNonFastforwards=true . Then the directory and file permissions can be edited like this:

cd <project_dir>/                         # Enter inside the project directory
chgrp -R <group-name> .                   # Change files and directories' group
chmod -R g+w .                            # Change permissions
chmod g-w .git/objects/pack/*             # Git pack files should be immutable
find -type d -exec chmod g+s {} +         # New files get directory's group id

Footnotes

¹ https://stackoverflow.com/questions/3242282/how-to-configure-an-existing-git-repo-to-be-shared-by-a-unix-group and https://stackoverflow.com/a/29646155/5641201