git 不尊重 core.sharedRepository=group（git push 后文件只读）答案

【问题标题】：git not honoring core.sharedRepository=group (file read-only after git push)git 不尊重 core.sharedRepository=group（git push 后文件只读）
【发布时间】：2016-04-01 04:22:25
【问题描述】：

我在本地网络上有一个共享的 git 存储库。开发人员克隆存储库，在本地进行更改，然后推送更改。通过 ssh 访问共享存储库，开发人员使用个人登录凭据。所有用户都有相同的主组，它是 repo 中所有文件/目录的相同组。我使用 find 命令确保所有目录都是 775，所有文件都是 664。 repo 配置有 core.sharedRepository = group。 repo 是使用 git init --bare 创建的。共享设置（文件权限和 core.sharedRepository=group）是在创建、克隆和推送一些更改后设置的。

我看到的问题是，在推送之后，修改后的文件会将权限从 -rw-rw-r--(664) 更改为 -r--r--r-- (444)。由于权限更改，后续推送同一文件将失败。

我可以使用下面列出的 find 命令清理 repo，但如果我能从一开始就避免这种情况发生就好了。

find repoDir -type f -not -writable -exec chmod 664 {} \;
find repoDir -type d -not -writable -exec chmod 775 {} \;

问题：为什么 git 不支持 core.sharedRepository 设置？

服务器 repo 正在运行 git 1.8.4.2

运行 gitbash 1.8.0 或 egit 3.0.3 的客户端仓库

gitbash 输出示例：

编辑文件并推送（成功）

developer@workstation /repo (dev)
$ git push
developer@server password:
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 366 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://developer@server/git/repo
   35b5daa..22b443a  dev -> dev

编辑文件并推送（失败）

developer@workstation /repo (dev)
$ git push
developer@server password:
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 368 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://developer@server/git/repo
 ! [remote rejected] dev -> dev (unpacker error)
error: failed to push some refs to 'ssh://developer@server/git/repo'

developer@workstation /repo (dev)
$

更新：

我只是重复了这个例子并没有失败 - 看起来这次 git 将更改放入对象下的新文件中。新文件具有我没想到的只读权限，但推送至少有效。

【问题讨论】：

请举例说明“失败”的推送命令。你所描述的似乎是正确的行为：有人推送修订版 X，git 将其存储为只读文件（顺便说一句，你不应该搞砸），没有其他人可以再次推送修订版 X。
用 git bash 输出更新问题
需要更多信息。由于 Git 的数据库是不可变的对象存储，因此预计对象文件是只读的。我怀疑.git/objects 的权限仍然不正确，尽管您使用了find 命令。如果我理解正确-writable 仅适用于运行find 的用户，那么如果一个目录由当前用户拥有但不是组可写的，则不会执行 chmod。真的没有理由不简单地为第二个 find 命令单独执行 -type d。
我期望 git 服务器存储库中的 objects/xx/ 子目录下的文件在将 sharedRepository 配置项设置为 group 的情况下保持其 664 权限。推送到共享仓库后，这些文件重置为 444 是否正常？

标签： git

【解决方案1】：

请注意，在创建文件时，其访问权限位将受到当前进程的umask 的屏蔽，因此如果您的服务器端git 进程使用umask 077 运行, "group" 和 "others" 位的三元组在调用open(2) 时，无论进程为文件设置哪种访问模式，都将始终为0。

我不确定 Git 是否尝试显式执行 chmod()s（在 Git 的代码中很少调用 chmod(2)，而且它们似乎与处理推送操作无关。

对sharedRepository 的Git 代码库进行Grepping 会得出，读取此设置的唯一位置是setup.c 中的git_config_perm 函数，然后调用它的唯一位置是builtin/init-db.c 文件，我认为，提示此设置仅影响数据库的创建（即git init）。

我不知道该从哪里开始，只是分享我的发现。

【讨论】：

core.sharedRepository 设置会影响大多数变异操作。它也从check_repository_format 中的setup.c 调用，这是大多数操作的前身。（参见path.c 中的calc_shared_perm 和adjust_shared_perm。）
我是否需要确保每个用户的 ~/.[shell]rc 文件中都有“umask 002”才能更新我的服务器 repo 有 664 权限？

【解决方案2】：

如果您启用 core.sharedRepository=group，请确保连接的用户是该组的成员。在我们的例子中，我们使用 'git' 用户。

【讨论】：

我目前无法重现该问题，但如果我以后遇到它，我会记住您的建议。