Ответ 1
Примечание. Я предполагаю, что вы используете механизм доступа на основе SSH, при этом каждый пользователь регистрируется на сервере в качестве своего собственного пользователя (т.е. у вас нет нескольких пользователей для входа в одну учетную запись для доступа к репозиторию). Если это предположение неверно, то следующий ответ может оказаться нецелесообразным.
Настройки core.sharedrepository вашего личного репозитория и umask, которые вы используете для доступа к нему, не имеют отношения к владению и разрешениям, используемым в удаленном репозитории.
Настройка core.sharedrepository - 0660 в удаленном репозитории - это правильный способ получить то, что вы говорите. Umask доступного пользователя на удаленной стороне также не имеет значения, поскольку Git переопределяет маску, когда видит значение 0xxx для core.sharedrepository. Вам необходимо убедиться, что все файлы и каталоги принадлежат группе вашей общей группе и что разрешения правильные (2770 для всех каталогов (или просто 770 для систем BSD-ish); 440 для файлы под objects/?? и /objects/pack/; 660 для других файлов).
Нормально, что новый файл принадлежит пользователю пользователем, который его создал. В системах, отличных от BSD, вам нужен бит setgid (бит 2000) в каталогах, чтобы новые записи наследовали владельца группы его родительского каталога. Пользователь-владелец редко наследуется (FreeBSD может быть настроен для этого с битом setuid, но это не используется в обычных конфигурациях). Таким образом, все файлы и каталоги должны иметь одного и того же общего владельца группы, но каждая запись в репозиторий (например, push) оставит некоторые файлы и/или каталоги, которые принадлежат пользователю пользователем записи 1 (т.е. не требуется, чтобы любой пользователь (ваш rUser?) был владельцем всех файлов и каталогов, любой пользователь, которому нужен доступ к репозиторию, должен быть членом общей группы).
<суб > 1 Каждый пользователь, очевидно, будет владельцем любых файлов/каталогов, которые они создают, но они также будут владельцем большинства файлов, которые они изменяют, поскольку Git использует "атомарные перезаписывания" (он записывает новый контент в новый отдельный файл в том же каталог, а затем переименовывает его поверх исходного файла). Суб >
Возможно, есть ошибка в том, что Git переопределяет umask для новых файлов. Какие файлы имеют слишком большие разрешения? Какая версия Git находится ли вы на удаленном конце для доступа к репозиторию? Какую ОС вы используете на удаленном конце?
Мне не удалось воспроизвести эту проблему с помощью Git 1.7.4.1 с двумя пользователями и общей группой на моей машине Unixy.
Вы можете попробовать немного упростить сценарий. Попробуйте нажать на удаленный репозиторий непосредственно с самого сервера (т.е. Сделать локальный клон и нажать на откидную ветвь). Выполнение локального доступа упрощает проверку ваших предположений (umask; uids; gids; пользовательское и групповое владение и разрешения файлов и каталогов до и после нажатия), чем когда у вас есть транспорт в некотором роде (либо Git собственные SSH-транспорты, либо сетевая файловая система, которая не может отображать идентификаторы и разрешения с полной точностью).