Under Ubuntu and Debian the last committed files are getting the execution bit set, when I try a checkout afterwards. It's quite strange and driving me nuts:

$ ls -l file
-rw-r--r-- ... file

# on branch master:
$ git commit -m 'mode is 644' file
[master 0123456] mode is 644
 1 files changed, 1 insertions(+), 1 deletions(-)
# All ok

$ git checkout dev-branch
Switched to branch 'dev-branch'
# Seemingly all ok, but file now has the exec bit set

$ git merge master
Updating 6543210..0123456
error: Your local changes to 'file' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.
# Oops...

$ ls -l file
-rwxr-xr-x ... file

Has anyone an idea, when and why the execution bit slips in? core.filemode is set to true.

I have the file open in vim during the branch switching, if that's important somehow.

Addendum 1: It's the checkout, where the permissions are screwed up. I can play the game on and on:

$ git br
* master

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout master

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

# ...and so on ad inf.

Addendum 2: This happens, by the way, for every file in this repository, that I commit. After the successful commit I can't switch branches without the permission screw-up.

  • Have you checked the permissions at the #seemingly all ok step... – RobotHumans Nov 5 '10 at 6:29
  • I agree here. On dev-branch, 'git-log master...HEAD -- file' and see if anything has changed between the branch and now on that file. – yuriismaster Nov 5 '10 at 8:50
  • @aking1012: Yes, at that point the file modes already changed. I'll update the question. – Boldewyn Nov 5 '10 at 9:49
  • @yuriismaster: git-log shows no output at all, for neither combination of master, dev-branch or HEAD (which is strange, isn't it? Shouldn't the command print the last commit message from master?) – Boldewyn Nov 5 '10 at 9:52
  • 2
    What filesystem are you on? – bitmask Nov 7 '10 at 22:20

Not a Git user, but I believe that Git stores the entire file permission mask.

That means that you have once set the file to executable, which Git picked up and replicated in the repository. Therefore you must change the file's permission mask itself before committing.

To make Git ignore such changes, use

git config core.filemode false

From git-config(1) :

       If false, the executable bit differences between the index and the
       working copy are ignored; useful on broken filesystems like FAT.
       See git-update-index(1). True by default.
  • 1
    Actually, I try hard to commit the files with the correct permissions. I even re-committed all files after chmod'ing them. Since I work on Windows from time to time (not with this repo, though), I know about core.fileMode, but I hoped to be able to leave it true. – Boldewyn Nov 5 '10 at 9:13
  • It might even be a bug in git when working on what they call "broken filesystems". There are no broken filesystems, only broken software. – harrymc Nov 5 '10 at 9:42
  • 4
    i have to agree with the git developers that fat is broken – RobotHumans Nov 5 '10 at 13:44
  • 3
    OK, it was the file system. I couldn't reproduce it on another machine, where the directory is mounted via NFS. On the main machine it is, as I said, CIFS. When I asked on the git mailing list, I got the answer, that CIFS is broken concerning execution bits. Darn! – Boldewyn Nov 9 '10 at 21:36
  • 2

Did you check whether there is a custom hook that is executed during commit or checkout? There might be some custom hooks tampering with your files. Checkout the githooks manpage.

Hooks are basically little programs called by git at certain events (commit, checkout etc.).

  • Good try, but my .git/hooks directory is untouched. – Boldewyn Nov 6 '10 at 13:02

have you tried git commit -m 'mode is 644' file on branch dev-branch

to me it looks like what is happening is you are changing permissions on main then pulling down the dev branch that has the wrong permission, clobbering your local permission. then trying to commit again. either clone, change, commit, merge; or try changing the file individually with a single file commit into dev then merge

  • Actually, I never touch permissions in the original scenario. All permission changing is done by git in the 'checkout' step. – Boldewyn Nov 6 '10 at 13:00
  • ...that is, I did some chmoding once on the files, but I can't unfortunately remember, if the problem started to occur right afterwards. I think, it did not. – Boldewyn Nov 6 '10 at 13:08
  • i tried to replicate you problem and i can't – RobotHumans Nov 8 '10 at 20:56
  • That's because you don't work on a mounted CIFS ;-). I forgot the +1 for the try, thanks! – Boldewyn Nov 11 '10 at 12:18

There are good answers at these links.




Essentially you need to git update-index --chmod=(+|-)x <file> and this will add a change that you then need to commit and push to have the permissions added/removed.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.