$ git add test-file
$ git commit -m \'first commit\'
create mode 100644 test-file
$ git push
$ git update-index --add --chmod=+x test-
MSYS is not the problem. Even if MSYS chmod
doesnt work (it doesnt), Git has a built in way of getting around that problem, ie git update-index --chmod=+x
. Let it be clear that git update-index only messes with the index (staging area), not the local repository (working directory).
I am convinced the problem is with GitHub. On GitHub if a file is initially pushed with mode 100775, all is well. If a file is initially pushed as 100644 it causes a problem. Attempts to change the file mode will succeed with git add
, succeed with git commit
, succeed with git push
, and even show up in the GitHub file history, but not be reflected on the "blob/master" page on GitHub.
Update
From: Petros Amiridis (GitHub Staff)
Subject: How to change FIle Mode on GitHub?
I have some good news. Our awesome team has just confirmed it is a caching bug on our end. Our team has deployed a fix.
I think the problem is that MSYS, on which the Windows implementation of git is based, doesn't handle chmod
properly.
(EDIT: The other answer says MSYS is not the problem, which certainly seems plausible.)
My guess is that the command
git update-index --add --chmod=+x test-file
works by updating the metadata in the local repository (which should work) and changing the permissions on the file (which doesn't), putting the local repository into an inconsistent state.
You should be able to back out of this by undoing the update-index
:
git update-index --add --chmod=-x test-file
git commit -m 'change mode back'
git push
to get the repository back into a consistent state, and then making the change in a non-Windows copy of the repository. If you don't have access to a Linux or other Unix-like system, Cygwin includes git
(not by default, but you can install it via setup.exe
) and gives you an environment in which chmod
actually works. The default shell for Cygwin is bash, so the environment should be familiar if you've been using git bash.
The file still won't appear to be executable when you look at it from the git bash shell, but it should show up as 100755
in the GitHub web interface.