Git set create mode to 100664 when pushing new folder/files to shared repo

Question

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.

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.

When I'm on my local and I commit a new folder/file it states the below with the create mode of 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.

On the shared repo we have core.sharedrepository = 0660 which I thought meant it would set permissions as I needed. Also our umask in our .bashrc is set to 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.

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

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 0002 everytime anyone pushes.

Answer 1

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.

core.sharedrepository only deals with the file permissions of the git database, not the permissions of the files stored in the repository.

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

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:

$ 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

Answer 2

It's caused by your filemode=false

refer to 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