up vote 30 down vote favorite
23
share [g+] share [fb]

I have a Git repository on a staging server which multiple developers need to be able to pull to. git-init seems to have a flag very close to what I'm looking for: --shared, except I'd like multiple people to pull to that repository, as well. The git-clone's --shared flag does something entirely different.

What's the easiest way to change an existing repository's permissions?

link|improve this question
feedback

7 Answers

up vote 19 down vote accepted

Permissions are a pest... basically, you need to make sure that all of those developers can write to everything in the git repo. If you put all the developers in a specially-created group, you can, in principle, just do:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

Then change the umask for the users to 002, so that new files get created with group-writable permissions. The problems with this problem are legion; if you're on a distro that assumes a umask of 022 (such as having a common 'users' group that everyone is in by default), this can open up security problems elsewhere. There's also the problem that sooner or later something is going to stuff up your carefully crafted permissions scheme and then the repo is out of action until you get root again and fix it up (rerunning the above commands, basically).

A superior solution, though one which is 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 what an extended ACL is is the ability to set your r/w/x attributes on more than just the default "user/group/other" sets. So, again, you create your group, then run:

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

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 that same ACL applied (the second line).

Hope that gets you on your way.

link|improve this answer
9  
git init has a parameter called --shared which sets up the core.sharedRepository variable for group work. You can also set the variable on an existing repository. That removes the need of manually setting the umask as git will set it to a sane value before manipulating files. – ptman Feb 17 '10 at 9:04
2  
+1 for POSIX extended attributes - news to me! – RobM Nov 2 '11 at 15:08
When I did chmod -R g+swX, it made Git very unhappy and it decided it wasn't a git repository anymore ("repo does not appear to be a git repository"). I had to chmod g-s all of the files. To just set the setgid bit on the directories, try find /path/to/repo -type d -print0 | xargs -0 chmod g+s. Still do the chgrp -R thegroup /path/to/repo. – rescdsk Apr 25 at 19:01
feedback
up vote 20 down vote

if you created the repository (or cloned a new bare repo off an existing one) with

$ git init --shared=group

or

$ git init --shared=0xNNNN

Git is supposed to handle permissions above and beyond what your default umask provides. At last this is true on my version of Git (1.6.3). Of course this assumes your users are in the same group.

If I needed management of users in multiple groups with varying degrees of read/write however, I'd go with gitosis. I've also heard mention of gitolite (http://github.com/sitaramc/gitolite), a gitosis fork that is suppossed to provide branch level permissions, can't say I've every used it personally though.

link|improve this answer
This is definitely the correct answer. – elliottcable Dec 5 '11 at 7:45
I had this issue and this is by far the best answer. The only problem is that the --shared argument takes in an octal, not hexadecimal. I have confirmed this in the source of Git 1.7.8 and the second example should be git init --shared=0NNN. – qpingu Jan 25 at 5:42
feedback
up vote 9 down vote

This has not been said, so I want to quickly add it.

To ensure that permissions issues do not crop their ugly head, make sure to set the following on your git shared repository's config file:

[core]
    sharedRepository = true

This will ensure that your system's "umask" settings are respected.

link|improve this answer
2  
According to git-config(1) (kernel.org/pub/software/scm/git/docs/git-config.html) core.sharedRepository, you need to set this to "umask" or "false" to have git respect the user's umask. – David Schmitt Aug 12 '11 at 10:05
2  
This and user35117's answer is correct. Note that "true" is the same as "group", and this can be set with the command git config core.sharedRepository true. – ColinM Dec 22 '11 at 3:43
feedback
up vote 6 down vote

The Git User Manual describes how to share a repository in several ways.

More complicated, though feature-full ways to share repositories are:

We use GitHub for a team of 6 developers.

link|improve this answer
I like Gitosis. It's a pretty effective way to control access based on public keys. – Mike Mazur Jun 17 '09 at 7:42
How do any of these solutions solve the problem of "I'd like multiple people to pull to that repository"? – womble Jun 17 '09 at 7:59
have a look at gitosis. that one solves your problem. – pilif Jun 17 '09 at 8:43
2  
When you share the repository, people will be able to pull from it. They'll likely need to clone it, or add a remote branch. The documentation I linked will very clearly walk you through solving your issue; I've used all the methods described to help developers collaborate source code with Git. To my knowledge ServerFault isn't for handholding. – jtimberman Jun 17 '09 at 17:34
2  
I have to agree with using Gitosis. It gets around the permissions issue by using a single account authenticated by multiple SSH keys. It is also managed entirely itself via git commits. – Jeremy Bouse Jun 18 '09 at 18:42
show 2 more comments
feedback
up vote 3 down vote

Also look at gitolite for hosting your git repository. Gitosis apparently isn't being developed anymore.

link|improve this answer
feedback
up vote 3 down vote

One way to fix permissions in the shared repository, so users won't have permission problems when pushing, is to create a post-update hook script which will do just that. This should work in any git version.

Suppose you have a shared repository in /myrepo.git. All files in that repository belong to say mysharedgroup. All users pushing to that repository should belong to mysharedgroup also. Now create the following file (changing mysharedgroup to your preferences):

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null
link|improve this answer
the right answer for when users have different default groups – Pat Nov 23 '11 at 23:42
Setting the setgid bit on a directory will cause files that users create to inherit the same group ownership as the directory (if the users belong to that group). Even if it's not the users' default group. Then this hook is not needed. This is what @womble's answer (and my comment on it) do. – rescdsk Apr 25 at 22:21
feedback
up vote 1 down vote

You can use git-daemon to share the repository. Read the documentation for git-daemon for more information.

EDIT:

Also check this article 8 ways to share your git repository.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.