CODEWITHSUNDEEP
gitgit-gui
concept47
concept47

Reputation: 31826

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

For some reason, when I initially did a pull from the repository for a git project of mine, I got a ton of files in my working copy that have no discernible changes made to them, but keep showing up in my unstaged changes area.

I'm using Git Gui on Windows xp, and when I go to look at the file to see what has changed. All I see is:

old mode 100755  
new mode 100644

Does anyone know what this means?

How can I get these files out of my list of unstaged changes? (Very annoying to have to go through 100's of files, just to pick out files I've recently edited and want to commit).

Upvotes: 1034

Views: 375514

Answers (19)

GaTechThomas
GaTechThomas

Reputation: 6123

If you're developing in Windows in a linux devcontainer, using the same Windows and WSL version of the folder, you may want to take the following steps:

  1. Unset the filemode in local repo scope (i.e., run this command from within the repo folder hierarchy):

    git config --unset --local core.fileMode

  2. In Windows, set the filemode to false at the global scope (i.e., run from anywhere in Windows):

    git config --global core.filemode false

  3. In the container, set the filemode to true at the global scope (i.e., run from anywhere in the linux container):

    git config --global core.filemode true

Now you won't see the modified files that don't have any file content changes.

Also, you'll may want to make this change in the devcontainer.json file's postCreateCommand option so that it persists when the container is rebuilt.

Upvotes: 2

NovelX
NovelX

Reputation: 1401

Setting core.filemode to false does work, but make sure the settings in ~/.gitconfig aren't being overridden by those in .git/config.

To know for sure where the core.filemode setting is coming from, run the following command (works on any OS) from the repository's root folder (or any folder under the root):

git config --show-origin --show-scope --get-all core.filemode

Upvotes: 130

viik_yh
viik_yh

Reputation: 21

Execute this command: chmod 755 xxx replace "xxx" with the path of the file, then hopefully things will go right. The command set the priviledge level back from 100644 to 100755

Upvotes: 1

Dave M
Dave M

Reputation: 1

Run git from WSL2 for full Linux compatibility then there is no need for workarounds like flipping core.filemode before and after a commit.

Upvotes: 0

Michael Weigel
Michael Weigel

Reputation: 51

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

Upvotes: 5

riley
riley

Reputation: 2467

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

Upvotes: 2

bkm
bkm

Reputation: 329

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

Upvotes: 23

Goddard
Goddard

Reputation: 3069

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

Upvotes: 1

eballo
eballo

Reputation: 777

This worked for me:

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

Upvotes: 12

K. Symbol
K. Symbol

Reputation: 3702

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.

Upvotes: 89

auspicious99
auspicious99

Reputation: 4331

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)

Upvotes: 8

Wae
Wae

Reputation: 116

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

Upvotes: 2

Collin Krawll
Collin Krawll

Reputation: 2530

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.

Upvotes: 0

Scott Willeke
Scott Willeke

Reputation: 9345

I've encountered this problem when copying a git repo with working files from an old hard drive a couple times. The problem stems from the fact that the owner and permissions changed from the old drive/machine to the new one. The long and short of it is, run the following commands to straighten things out (thanks to this superuser answer):

sudo chmod -R -x . # remove the executable bit from all files

The former command will actually resolve the differences that git diff reported, but will revoke your ability to list the directories, so ls ./ fails with ls: .: Permission denied. To fix that:

sudo chmod -R +X . # add the executable bit only for directories

The bad news is that if you do have any files you want to keep executable, such as .sh scripts, you'll need to revert those. You can do that with the following command for each file:

chmod +x ./build.sh # where build.sh is the file you want to make executable again

Upvotes: 61

IskandarG
IskandarG

Reputation: 333

This happens when you pull and all files were executable in the remote repository. Making them executable again will set everything back to normal again.

chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder

You might need to do:

chmod -x <file> // Removes execute bit

instead, for files that was not set as executable and that was changed because of the above operation. There is a better way to do this but this is just a very quick and dirty fix.

Upvotes: 3

kEnobus
kEnobus

Reputation: 66

I had just the one troublesome file with the changed permissions. To roll it back individually, I just deleted it manually with rm <file> and then did a checkout to pull a fresh copy.

Luckily I had not staged it yet.

If I had I could have run git reset -- <file> before running git checkout -- <file>

Upvotes: 0

Amber
Amber

Reputation: 527458

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

Upvotes: 1780

SuperNova
SuperNova

Reputation: 27486

It seems you have changed some permissions of the directory. I did the following steps to restore it.

$  git diff > backup-diff.txt                ### in case you have some other code changes 

$  git checkout .

Upvotes: 3

Doppelganger
Doppelganger

Reputation: 20855

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

Upvotes: 1

Related Questions