Git changes the permissions on a single file unexplainably

Question

I am the only person involved with this git project. Every time I edit files at my local Ubuntu repository, then push to Bitbucket and pull to my production repository, git changes the edited files to -rwxrwxr-x 775. Apache doesn't like this.

Local system: git version 1.8.1.2 on Ubuntu Linux

Production system: git version 1.7.12 on CentOS/Red Hat Linux

When I fix permissions to 755, then do

git diff

or

git diff -p

It shows nothing.

At my local repository, the permissions are 755 and the files are all owned by haws. At my production repository, all other permissions stay at 755, and all files including contact.php are owned by my username.

At both the local and the production repository, I changed core.filemode as follows in an attempt to stop this behavior,

core.filemode = false

I've had mysteries like this in collaborative projects, so I'd really like to understand what's happening.

1. What can I do to see git's reason for changing the permissions of this file?
2. How can I get git to stop changing it?

I have also tried to find the solution here: Prevent Git from changing permissions on pull to no avail.

My Final Solution (thanks to VonC's guidance):

1. Thanks to VonC's good explanations, I was brave enough to figure out that every time I was logging into my server, my umask was going back to 0002. So I created a user startup script (.bashrc or in my case .bash_profile) at my Linux host that sets

   umask 0022

or using symbolic notation (for a little added value)

umask u=a,g-w,o-w 

or

umask u=a,go-w 

(Allow all permissions for user, disallow write permissions for group and others)

That solved my issue.

2. I had previously set git config core.sharedRepository true, but that was not my issue, and I removed the setting once the issue was resolved.

Answer 1

As mentioned in "Wrong file permission when using git pull in a hook"

Git does not store permissions, apart from the executable bit.
So, on checkout, files are created with the default permissions, which depend on your umask.

In your case: umask 0022 should be set when you are pulling.
(that is what I was mentioning in the answer you saw "Prevent Git from changing permissions on pull")

This assume that you have, in the target repo, a configuration like:

git config core.sharedRepository true

The other solution is mentioned in "How do I share a Git repository with multiple users on a machine?", where you would make sure to pull in a repo initialized like so:

git init --shared=0022

---

The OP Tom Haws adds in the comments:

Do you know why git at my client's production server is able to pull without having file permission changes even when there is no sharedRepository entry in that repository's config?

Maybe because umask was set by default to 0022 already, meaning that, by default, the git shell inherits the umask of the system.
Changing the umask requires a core.sharedRepository set to true to take it into account instead of taking the umask of the parent process.
That, or because the repo was created with --shared=0022.

To see how an umask can be set (system wide or user-wide), see "How to set system wide umask?"

To check an umask just before a git command (which would inherit its value), simply type:

umask