Re: [remote rejected] master -> master (n/a (unpacker error))

From: Greg Troxel <gdt@ir.bbn.com>
Date: May 13, 2010, 12:05 UTC
Message-ID: <rmiy6fo3t3n.fsf@fnord.ir.bbn.com>
In-Reply-To: <AANLkTilz_gbHl_RLyOuvEIdjPoUDIfZTUCpnswdHTiej@mail.gmail.com>

Robert Buck <buck.robert.j@gmail.com> writes:

Show 5 quoted lines

> Yes, the repository is shared by several people, and in geographically
> different locations, ssh-ing to the same host, under different groups.
> So your recommendation would be to use --shared. But this won't work
> so well out in the wild will it? Meaning, what if people's accounts
> are NOT under the same group that is?

Git simply rides on filesystem permissions. So you choose a group to control access to the repository, chgrp -R the repo to that group, and config shared=0660. Then you put people in the group to give them access; it doesn't have to be their primary gid. I don't follow your objection; you seem to want to use groups to control access yet not set up a group for the repo.

On some systems (e.g. BSD), directories automatically inherit the parent dir's group. On others, you need setgid bit. I have the impression that git will deal with this all correctly if you simply have "sharedrepository = 0660" under [core] in config; I would expect it to chgrp new files/dirs as needed to match the repo dir's group.

I don't see how chroot would change the issues above.