59

I use git on Windows via cygwin and soon decided to use filemode=false (since otherwise I've got a lot of changes after the initial git clone). I'm definitely not interested in tracking permission at all, the only think I need is for some files to be executable. From time to time, I find that the x flag on some files gets lost and I strongly suppose it's because of git.

I'd be happy with a solution allowing to execute chmod a+x ... when needed.

maaartinus
  • 44,714
  • 32
  • 161
  • 320

4 Answers4

107

I believe you want git update-index --chmod=+x <file>, followed by a commit.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • I don't think it helps, since I'm using `filemode=false`, so I assume I have to do something after getting files out of git (as opposed to putting them in git). Something which applies whenever git changes or creates a file. Moreover, it should run automatically. – maaartinus Aug 13 '11 at 09:41
  • 2
    [The docs](http://www.kernel.org/pub/software/scm/git/docs/git-update-index.html#_configuration) specifically recommend this command for systems where filemode=false. If I understand it correctly, that setting only applies to _automatic_ detection of permission changes. Git still stores a filemode, which is the first column when you do a `git ls-tree HEAD`. If it shows up as 644 instead of 755, then git won't set the executable bit when it writes that file. – Karl Bielefeldt Aug 13 '11 at 10:30
  • I see I was misunderstanding `filemode=false`. Somehow I thought, it would disable storing the bits, but "the executable bit differences between the index and the working copy are ignored" instead. – maaartinus Aug 13 '11 at 10:45
  • Now I get it... it works, but of course not if I checkout an older version. This is something I should have done after the first commit of the executable file (not it's too late since I really don't want to rebase the whole history). It's not perfect, but it helps, thank you. – maaartinus Aug 13 '11 at 10:54
  • You might consider a [post checkout hook script](http://www.kernel.org/pub/software/scm/git/docs/githooks.html#_post_checkout) to take care of the older versions. – Karl Bielefeldt Aug 13 '11 at 11:04
  • This would be easy and practical, but from the description I'm not sure if it always applies, e.g., after rebase. Does it? OTOH, I'm not going to do a lot of with the old commits, so together with the above it's probably sufficient. – maaartinus Aug 14 '11 at 04:12
  • 2
    I use the Cygwin version of git. My co-workers use the "git bash" shell, which uses MSYS rather than Cygwin. They *should* work happily together, but *.bat files that other people check in appear to be executable for them, but not for me. I think that MSYS implicitly makes *.bat files executable when it creates them, but doesn't bother to preserve the executable bit when they're checked in; Cygwin doesn't do this. (I run `chmod +x` and check them in when needed.) – Keith Thompson Aug 16 '11 at 01:51
  • @Keith Thompson: Did you try what Karl wrote? I think it should help. – maaartinus Aug 17 '11 at 06:12
6

You should start with git update-index --chmod=+x <file>.

But this does not change your working copy, for that:

git checkout .
Alexander Pogrebnyak
  • 44,836
  • 10
  • 105
  • 121
5

I've met the same problem. git update-index --chomd=+x doesn't work for me.

I use chmod +x , then commit, it works perfect.

think2010
  • 121
  • 1
  • 2
1

For me, this command worked:

git add --chmod=+x -- <file>

Commit after that (and push), done.

In Bitbucket pull request before:

before

After (just the one commit):

after

After (all changes):

enter image description here

The difference between git update-index and git add is explained in this StackOverflow Question.

jasie
  • 2,192
  • 10
  • 39
  • 54