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).
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: Config ONLY for current repo: git config core.filemode false. Config globally: git config --global core.filemode false.
It means that the file mode changed from 755 to 644, but the contents were not altered. git diff is exactly what you are looking for - it shows the changes from unstaged files to the last commit. git diff --cached is for staged files. Follow this answer to receive notifications.
Create Mode: - Tells about permissions given to that file, i.e., File permissions. Here, 100644 means the file is a normal file.
false : git does not track it.
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
Setting core.filemode
to false does work, but make sure the settings in ~/.gitconfig
aren't being overridden by those in .git/config
.
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:
Config ONLY for current repo:
git config core.filemode false
Config globally:
git config --global core.filemode false
Add in ~/.gitconfig:
[core]
filemode = false
Just select one of them.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With