Brian Tanaka's Blog

[ Home | briantanaka.com | RSS 2.0 | 2010 Archive | 2009 Archive | 2008 Archive ]

Sat, 25 Oct 2008

Preserving Group Write on Git Objects in a Collaborative Repository

If you're having trouble with group permissions on git objects in a shared environment, read on.

Recently, I needed to set up a git repository to which a number of people would need to push. I used Don Marti's excellent article on LinuxWorld, Getting a static web site organized with git as a guide.

Everything went according to plan. I created a new user and group, added the user accounts of all the collaborators to the newly created group, made the home directory (where the repository would live) setgid, git init, created a subdirectory for the working files that would be served by Apache, and installed the post-update hook that keeps the working files checked out. (I'm breezing through these steps. You can get more detail by reading Don's article.)

At first everything worked correctly, but once multiple people had git pushed to the repository, we began running into permissions issues despite the setgid. They manifested roughly like so:

$ git push
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 376 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
error: unable to create temporary sha1 filename ./objects/tmp_obj_gBZ5Rl:
Permission denied

fatal: failed to write object

Inspection revealed that git objects were being written to .git/objects with the group write permissions bit off.

The solution turned out to be fairly straightforward. In the file .git/config, I added a line that read: "sharedRepository = group", like so:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        sharedRepository = group

Thereafter, new files in .git/objects were created with the proper permissions for group write. (However, note that new files are group-owned by the primary group of the user account via which the push was received. If the users collaborating on the project have different primary groups, and if those users do not share membership in that set of groups, you may still run into problems.)

Disclaimer: I'm far from being a git expert. Though this solution worked for me, you're advised to do additional research on your own. For example, while writing this post, I stumbled upon this article that has extra, useful looking information you should read: Converting a Shared Subversion Repository to Git (The section titled "Make the shared Git repository" in particular.)

Happy collaborating!

...

posted at: 11:11 | path: /git | permanent link to this entry

Made with PyBlosxom