How to find out what causes file permissions to change when checking out files with git?

Question

After pushing files to our server, the following post-receive hook is executed:

#!/bin/sh
export GIT_WORK_TREE=/home/user/www/
git checkout -f

However, files get a very odd 600 permission, and folders 700 upon checkout. This is not what I expect (on our other servers we get 644 and 755). From this thread I understand that git does not set permissions, so git is not to blame. My question is: what is? How can I figure out what the cause is of this issue?

I have already temporarily solved it by running an extra script upon checkout to fix the permissions, but I am interested in solving the root cause.

I'm using gitolite to manage the repositories, but I doubt that is the cause. But again, I'm happy to learn where I can start because at this point I'm not sure how to investigate this.

As per the initial answers I have looked into the umask settings on the server. The git user (that's the user used to upload the files), the umask setting is 0002. This is confirmed in the following exercise:

git@server:~$ umask
0002
git@server:~$ touch newfile
git@server:~$ ls -la newfile
-rw-rw-r-- 1 git git 0 Aug  5 10:46 newfile

Additional details:

• Linux used on both server side and development side
• In the local repo, permissions are 755 and 644
• filemode is set to true in .git/config

Answer 1

As in "Git change default umask when update file", can you add umask to your hook?

#!/bin/sh
umask 002
export GIT_WORK_TREE=/home/user/www/
git checkout -f

That should set file permissions to 664 and directory permissions to 775.

---

Regarding gitolite specifically, check the umask section of the gitolite.rc file:

$UMASK, octal, default 0077

The default UMASK that gitolite uses gives rwx------ permissions to all the repos and their contents.
People who want to run gitweb (or cgit, redmine, etc) realize that this will not do.

The correct way to deal with this is to give this variable a value like 0027 (note the syntax: the leading 0 is required), and then make the user running the webserver (apache, www-data, whatever) a member of the 'git' group.

If you've already installed gitolite then existing files will have to be fixed up manually (for a umask or 0027, that would be chmod -R g+rX). This is because umask only affects permissions on newly created files, not existing ones.

Answer 2

However, files get a very odd 600 permission, and folders 700 upon checkout.

It looks like your shell has a restrictive umask setting, possibly umask 0177.

From this thread I understand that git does not set permissions, so git is not to blame.

No, it is the umask setting of your shell.

My question is: [...] [how] can I figure out what the cause is of this issue?

Run umask, it will tell you what is your current setting. It's like to be 0177 or similar. If you want to know why, you need to look through the rc files used by /bin/sh, most probably .profile or .bashrc, and other files sourced.

You can have very restrictive umask settings but override them in your script, by adding a umask line as @VonC suggested.