Git changes permissions on one file inexplicably

Question

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

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 at 755, then

git diff 

or

 git diff -p 

He does not show anything.

There are 755 permissions in my local repository, and all files belong to haws. In my product repository, all other permissions remain at 755, and all files, including contact.php, belong to my username.

In the local and production repository, I changed core.filemode as follows, trying to stop this behavior,

 core.filemode = false 

I had such secrets in collaborative projects, so I really would like to understand what is happening.

• What can I do to see git reason for changing permissions of this file?
• How can I get git to stop changing it?

I also tried to find a solution here: Prevent git from changing permissions on click to no avail.

My final decision (thanks to VonC leadership):

• Thanks to VonC's good explanations, I was brave enough to realize that every time I logged into my server, my umask returned to 0002. Thus, I created a custom script run (.bashrc or in my case .bash_profile) on my Linux host that installs

  umask 0022

or using symbolic notation (for small added value)

 umask u=a,gw,ow 

or

 umask u=a,go-w 

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

This solved my problem.

2. I previously set git config core.sharedRepository to true, but this is not my problem, and I deleted the parameter after fixing the problem.

Answer 1

As mentioned in " Incorrect file resolution when using git pull the hook "

Git does not save permissions except the executable bit .
Thus, during verification, files are created with default permissions, which depend on your umask .

In your case: umask 0022 should be installed when you pull.
(here is what I mentioned in the answer that you saw " Prevent git from changing permissions when deleting ")

Suppose you have a configuration in the target repo such as:

 git config core.sharedRepository true 

Another solution is mentioned in the section “ How can I share the git repository with several users on the machine? ”, Where you would have to pull the repo initialized like this:

 git init --shared=0022 

---

OP Tom Haws adds in comments:

Do you know why git on my client production server can pull without changing file permissions, even if there is no sharedRepository entry in this repository?

Perhaps because umask was set to 0022 by default, which means that by default, the git shell inherits the umask system.
Changing umask requires core.sharedRepository set true to take it into account, rather than accepting the umask parent process.
This is either because the repo was created using --shared=0022 .

To learn how to install umask (on a system or user scale), see " How to set the width of an umask system? "

To test umask immediately before the git command (which inherits its value), simply type:

 umask