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