Menu
When Git checks out files, it by default uses the umask of the file on the system, setting the executable bit if it's a directory or it's marked as an executable file. That's because Git removes and re-creates the file, so it doesn't preserve the permissions of the existing file.
Directories should have 755 permission; files should have 644 permission. That's a pretty good rule of thumb unless you expect members of your group to make changes to your repository.
@fooMonster article worked for me
# git ls-tree HEAD
100644 blob 55c0287d4ef21f15b97eb1f107451b88b479bffe script.sh
As you can see the file has 644 permission (ignoring the 100). We would like to change it to 755:
# git update-index --chmod=+x script.sh
commit the changes
# git commit -m "Changing file permissions"
[master 77b171e] Changing file permissions
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 script.sh
By default, git will update execute file permissions if you change them. It will not change or track any other permissions.
If you don't see any changes when modifying execute permission, you probably have a configuration in git which ignore file mode.
Look into your project, in the .git folder for the config file and you should see something like this:
[core]
filemode = false
You can either change it to true in your favorite text editor, or run:
git config core.filemode true
Then, you should be able to commit normally your files. It will only commit the permission changes.
Not working for me.
The mode is true, the file perms have been changed, but git says there's no work to do.
git init
git add dir/file
chmod 440 dir/file
git commit -a
The problem seems to be that git recognizes only certain permission changes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With