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

[Greg Troxel <gdt@ir.bbn.com>]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]


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

> 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.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]