Примечание. Я предполагаю, что вы используете механизм доступа на основе 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, либо сетевая файловая система, которая может не отображать идентификаторы и разрешения с полной точностью).