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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robert Buck <buck.robert.j@xxxxxxxxx> 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: pgp50KWzIGoYI.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]