How do I remove files saying "old mode 100755 new mode 100644" from unstaged changes in Git?

That looks like unix file permissions modes to me (755=rwxr-xr-x, 644=rw-r--r--) - the old mode included the +x (executable) flag, the new mode doesn't.

This msysgit issue's replies suggests setting core.filemode to false in order to get rid of the issue:

git config core.filemode false

This usually happens when the repo is cloned between Windows and Linux/Unix machines.

Just tell git to ignore filemode change. Here are several ways to do so:

1. Config ONLY for current repo:

    git config core.filemode false
   

2. Config globally:

    git config --global core.filemode false
   

3. Add in ~/.gitconfig:

    [core]
         filemode = false
   

Just select one of them.

This worked for me:

git ls-files -m | xargs -L 1 chmod 644

I have faced the same issue. And this save my life:

This will revert all the permissions to what the diff is so you are left with nothing, but the changes you made to the files.

https://gist.github.com/jtdp/5443498

git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never  \
| git apply

More details in https://stackoverflow.com/a/4408378/450383

This solution will change the git file permissions from 100755 to 100644 and push changes back to the bitbucket remote repo.

1. Take a look at your repo's file permissions: git ls-files --stage

2. If 100755 and you want 100644

Then run this command: git ls-files --stage | sed 's/\t/ /g' | cut -d' ' -f4 | xargs git update-index --chmod=-x

3. Now check your repo's file permissions again: git ls-files --stage

4. Now commit your changes:

git status

git commit -m "restored proper file permissions"

git push

The accepted answer to set git config core.filemode false, works, but with consequences. Setting core.filemode to false tells git to ignore any executable bit changes on the filesystem so it won't view this as a change. If you do need to stage an executable bit change for this repository anytime in the future, you would have to do it manually, or set core.filemode back to true.

A less consequential alternative, if all the modified files should have mode 100755, is to do something like

chmod 100755 $(git ls-files --modified)

which just does exactly the change in mode, no more, no less, without additional implications.

(in my case, it was due to a OneDrive sync with my filesystem on MacOS; by not changing core.filemode, I'm leaving the possibility open that the mode change might happen again in the future; in my case, I'd like to know if it happens again, and changing core.filemode will hide it from me, which I don't want)

You could try git reset --hard HEAD to reset the repo to the expected default state.

You can use the following command to change your file mode back. git add --chmod=+x -- filename Then commit to the branch.

This is like what bkm found, but it also takes into account any deleted files and only gives a warning while still applying the changes.

This works well to revert file mode settings from previous commit.

git diff -p --no-ext-diff --no-color --diff-filter=d | grep -E "^(diff|old mode|new mode)" | sed -e "s/^old/NEW/;s/^new/old/;s/^NEW/new/" | git apply

I just ran into this issue when diffing my branch with master. Git returned one 'mode' error when I expected my branch to be identical to master. I fixed by deleting the file and then merging master in again.

First I ran the diff:

git checkout my-branch
git diff master

This returned:

diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644

I then ran the following to fix:

rm bin/script.sh
git merge -X theirs master

After this, git diff returned no differences between my-branch and master.

A number of the solutions above will break if there are any deleted files.

This will list files that are only modified, and not deleted, and change them all to 755

git diff-files --name-only --diff-filter=d | xargs -L 1 chmod 755