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

Robert Buck [off-list ref] 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.