Git changes the permissions on a single file unexplainably
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 22.214.171.124 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 -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.
- What can I do to see git’s reason for changing the permissions of this file?
- 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):
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
or using symbolic notation (for a little added value)
(Allow all permissions for user, disallow write permissions for group and others)
That solved my issue.
- 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.
One Solution collect form web for “Git changes the permissions on a single file unexplainably”
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
sharedRepositoryentry 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.
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
To see how an
umask can be set (system wide or user-wide), see “How to set system wide
To check an
umask just before a git command (which would inherit its value), simply type: