Removing files saying "old mode 100755 new mode 100644" from unstaged changes in git

tags:

git
git-gui

views:

1427

answers:

+12 Q:

Removing 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).

+15 A:

That looks like unix file permissions modes to me (755=rwxrw_rw_, 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.

Amber 2009-08-10 22:34:45

+1. This means that git thinks that it can correctly set the executable bit on checked out files, but when it attempts to do so it doesn't work (or at least not in a way that it can read). When it then reads back the status of those files it looks like the executable bit has been deliberately unset. 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 it does mean that you have to manually do `git update-index --chmod=(+|-)x <path>`.

Charles Bailey 2009-08-11 06:49:42

you. my friend ... ARE AWESOME!!!! Thank you so much!

concept47 2009-08-12 02:26:51

If, like me, the mode changes are important, you can set core.filemode to false, commit your actual code changes, and then set core.filemode to true and git will preserve the file changes.

Michael T. Smith 2009-09-26 18:48:23

I have the same problem, but it was due to using the same git repro via SSH git cmd line, and through Git Extensions on a mapped drive in Windows! . . Solution was the same, added into "config" [core] filemode = false

IanVaughan 2010-03-18 09:07:48

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

Doppelganger 2009-08-11 03:38:11

If git wasn't able to set the executable bit correctly/consistently after a pull, it's not going to fair any better after a reset.

Charles Bailey 2009-08-11 06:34:15

Setting core.filemode to false does work. But you'd make sure the settings in ~/.gitconfig aren't be overridden by those in .git/config.

NovelX 2010-06-04 07:03:22

ansaurus

tags:

views:

answers:

Removing files saying "old mode 100755 new mode 100644" from unstaged changes in git

related questions