Nota: Supongo que está utilizando un mecanismo de acceso basado en SSH con cada usuario que inicia sesión en el servidor como su propio usuario (es decir, no tiene múltiples usuarios que inician sesión en una sola cuenta para acceder al repositorio). Si esta suposición no es cierta, entonces la siguiente respuesta puede no ser del todo útil.
El ajuste core.sharedrepository de su repositorio personal y la máscara de usuario que se utiliza para acceder a ella son irrelevantes para la propiedad y los permisos se utiliza en un repositorio remoto.
Configuración core.sharedrepository a 0660 en el repositorio remoto es la manera correcta de obtener lo que usted dice que quiere. El umask del usuario que accede desde el lado remoto también es irrelevante porque Git anulará la máscara cuando vea un valor 0xxx para core.sharedrepository. Debe asegurarse de que todos los archivos y directorios pertenezcan a su grupo común y que los permisos sean correctos (2770 para todos los directorios (o solo 770 para sistemas BSD-ish); 440 para archivos de objects/?? y /objects/pack/; 660 para otros archivos).
Es normal que un archivo nuevo sea propiedad del usuario que lo creó. En sistemas que no son BSD, necesita el bit setgid (el bit 2000) en los directorios para hacer que las nuevas entradas hereden el propietario del grupo de su directorio padre. El usuario propietario rara vez se hereda (FreeBSD puede configurarse para hacerlo con el bit de setuid, pero esto no se usa en configuraciones normales). Por lo tanto, todos los archivos y directorios deben tener el mismo propietario de grupo común, pero cada escritura en el repositorio (por ejemplo, inserción) dejará algunos archivos y/o directorios que son propiedad del usuario (es decir, no es necesario que un usuario (su rUser?) sea el propietario de todos los archivos y directorios, cualquier usuario que necesite acceder al repositorio debe ser miembro del grupo común).
Cada usuario tendrá, obviamente, fácil de poseer todos los archivos/directorios que crean, sino que será la mayoría de archivos también por el usuario propia que modificar debido a Git utiliza “reescrituras atómicas” (se escribe el nuevo contenido a un nuevo archivo separado en el mismo directorio, y luego lo renombra sobre el archivo original).
Quizás haya un error en la forma en que Git anula la umask en busca de nuevos archivos. ¿Qué archivos obtienen exactamente permisos demasiado amplios? ¿Qué versión de Git estás en el extremo remoto para acceder en el repositorio? ¿Qué sistema operativo está ejecutando en el extremo remoto?
No he podido reproducir este problema con Git 1.7.4.1 con dos usuarios y un grupo común en mi máquina Unixy.
Puede intentar simplificar un poco el escenario. Intente presionar al repositorio remoto directamente desde el servidor mismo (es decir, haga un clon local y empuje a una rama desechable). Hacer el acceso solo local hace que sea más fácil verificar sus suposiciones (umask; uids; gids; usuario, y propiedad del grupo, y permisos de archivos y directorios antes y después del envío) que cuando tiene un medio de transporte en el medio (Transportes propios basados en SSH de Git, o un sistema de archivos de red que podría no mapear ids y permisos con total fidelidad).
¿Cómo está accediendo al repositorio remoto? Parece que podría estar utilizando un método basado en SSH (URL del repositorio 'host: path' o' ssh: // host/path'). Si está utilizando un sistema de archivos de red en su lugar, podría estar complicando las cosas. –
Estoy accediendo usando ssh, y el sistema de archivos remoto es en realidad un sistema de archivos NFS (no estoy seguro de por qué el sistema de archivos afectaría algo aquí). – user10