将新文件夹/文件推送到共享存储库时，Git 将创建模式设置为 100664
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14325186/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git set create mode to 100664 when pushing new folder/files to shared repo
提问by Henesnarfel
Me and my colleagues have a shared Website repo. We are all on Windows 7 64 bit pushing to Ubuntu 10.04. Below is our setup in case this is in question.
我和我的同事有一个共享的网站存储库。我们都在 Windows 7 64 位推送到 Ubuntu 10.04。以下是我们的设置，以防万一。
local->hub->website
本地->中心->网站
We push to the hub, which is a bare repo, then with a post-update hook in the hub cds to the website repo and pulls the changes from the hub to the website. This is done because the website is live and always checked out and can't be pushed to.
我们推送到集线器，这是一个裸存储库，然后在集线器 cd 中使用更新后挂钩到网站存储库，并将更改从集线器拉到网站。这样做是因为该网站是实时的，并且始终签出并且无法推送到。
When I'm on my local and I commit a new folder/file it states the below with the create mode of 100644
当我在本地并提交一个新文件夹/文件时，它会以 100644 的创建模式说明以下内容
$ git commit -a -m "testing permissions"
[master 865b809] testing permissions
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test.php
When I push these changes to the repo it creates the folders as 755 and files as 644 when I need them to be 775 and 664. As long as I'm only editing files the permissions at least stay the same. The only problem is on creation.
当我将这些更改推送到 repo 时，它会在我需要将它们设置为 775 和 664 时将文件夹创建为 755，并将文件创建为 644。只要我只编辑文件，权限至少保持不变。唯一的问题在于创作。
On the shared repo we have core.sharedrepository = 0660which I thought meant it would set permissions as I needed. Also our umaskin our .bashrcis set to 002.
在我们拥有的共享存储库中core.sharedrepository = 0660，我认为这意味着它会根据我的需要设置权限。我们的umaskin our.bashrc也设置为 002。
Here is my local config
这是我的本地配置
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
It seems as though our local is determining the permissions and ignoring what is setup on our shared repo. How can I get the create mode to be 100664.
似乎我们的本地正在确定权限并忽略我们共享存储库上的设置。如何使创建模式为 100664。
EDIT
编辑
Hub config
集线器配置
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 0660
[receive]
denyNonFastforwards = true
Website config
网站配置
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
EDIT2
编辑2
As Kalle Pokki below pointed out in her comments. This issue is that when using GIT and pushing it is running non-interactively so my umask setup doesn't work. I've updated my post-update for my repo to set the umask to 0002everytime anyone pushes.
正如下面的 Kalle Pokki 在她的评论中指出的那样。这个问题是，当使用 GIT 并推送它时，它以非交互方式运行，所以我的 umask 设置不起作用。我已经为我的 repo 更新了我的 post-update 以将 umask 设置为0002每次有人推送时。
采纳答案by Kalle Pokki
From what I can tell, git doesn't store file permissions at the level you want. Having 644 or 664 files depends purely on umask.
据我所知，git 不会在您想要的级别存储文件权限。拥有 644 或 664 文件完全取决于 umask。
core.sharedrepository only deals with the file permissions of the git database, not the permissions of the files stored in the repository.
core.sharedrepository 只处理git数据库的文件权限，不处理存储库中文件的权限。
As you already have the post-update hook to check out the repository in the web server, I'd suggest to add a chmod script there. Something like
由于您已经有了 post-update 挂钩来检查 Web 服务器中的存储库，我建议在那里添加一个 chmod 脚本。就像是
find /path/to/website -type d | xargs chmod 775
find /path/to/website -type f | xargs chmod 664
EDIT: I'm quite confident your ssh/git server has different umask than what you have when logged in interactively. Perhaps you should set the umask explicitly at the beginning of the post-update hook. See the following where I have the additional file '1' in the tmp branch that doesn't exist in the master branch:
编辑：我非常确信您的 ssh/git 服务器具有与交互式登录时不同的 umask。也许您应该在更新后挂钩的开头显式设置 umask。请参阅以下内容，其中我在主分支中不存在的 tmp 分支中有附加文件“1”：
$ umask 0022
$ git checkout tmp
Switched to branch 'tmp'
$ ls -l 1
-rw-r--r-- 1 kp kp 5 2013-01-15 15:53 1
$ git checkout master
Switched to branch 'master'
$ umask 0002
$ git checkout tmp
Switched to branch 'tmp'
$ ls -l 1
-rw-rw-r-- 1 kp kp 5 2013-01-15 15:53 1
回答by yinyin.xiao
It's caused by your filemode=false
这是由您的 filemode=false 引起的
refer to http://www.gelato.unsw.edu.au/archives/git/0609/28190.html
参考http://www.gelato.unsw.edu.au/archives/git/0609/28190.html
Ignore executable bit when adding files if filemode=0.
If the user has configured core.filemode=0 then we shouldn't set the execute bit in the index when adding a new file as the user has indicated that the local filesystem can't be trusted.
This means that when adding files that should be marked executable in a repository with core.filemode=0 the user must perform a 'git update-index --chmod=+x' on the file before committing the addition.
Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano
如果 filemode=0，则在添加文件时忽略可执行位。
如果用户配置了 core.filemode=0，那么我们不应该在添加新文件时在索引中设置执行位，因为用户已经表明本地文件系统不可信。
这意味着在 core.filemode=0 的存储库中添加应该标记为可执行的文件时，用户必须在提交添加之前对文件执行“git update-index --chmod=+x”。
签字人：Shawn O. Pearce 签字人：Junio C Hamano
