Imagine web/ in my home directory has permissions that are Ubuntu 14.04's default (I think 775 for directories and 644 for files). Then I change them to something else (silly but just for example):
$ chmod -R 777 ~/web
$ cd ~/web
$ git status
Results in:
On branch master Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Why doesn't Git take into account owner and permission changes to files and directories?
tl;dr:
File system attributes (except for the executable bit) are out-of-scope for git.
Git is intended mainly for software development, specifically for storing source code files. In that context file permissions are meaningless.
In addition to that, it is not clear how git should even support file ownership, because different systems will have different user names. Who should own a file originally owned by "matt" if there is no "matt" on the system checking out?
To address your situation:
You question looks like you are (mis-)using git as a deployment tool. While that is possible, that is not what it was intended for, and using it as such has problems (one of which you just found). Consider using a proper deployment tool / package format - most languages/frameworks offer one (e.g. WARs for Java, Capistrano for Ruby etc.).
You can use this gist.
You store the permissions of your files and directories in a separate file named .git_cache_meta and no directly under git.
A full sample can be found here
Copied form the above post:
+# git bundle create mybundle.bdl master; git-cache-meta --store
+# scp mybundle.bdl .git_cache_meta machine2: #then on machine2:
+# git init; git pull mybundle.bdl master; git-cache-meta --apply
