如何从 Git 中的未暂存更改中删除显示“旧模式 100755 新模式 100644”的文件？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1257592/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I remove files saying "old mode 100755 new mode 100644" from unstaged changes in Git?
提问by concept47
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 changesarea.
出于某种原因，当我最初从我的一个 git 项目的存储库中提取时，我在我的工作副本中得到了大量文件，这些文件没有对它们进行明显的更改，但一直出现在我的unstaged changes区域中。
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:
我在 Windows xp 上使用 Git Gui，当我查看文件以查看发生了什么变化时。我看到的只有：
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).
如何从我的未暂存更改列表中获取这些文件？（不得不浏览 100 个文件，只是为了挑选出我最近编辑过并想要提交的文件，这很烦人）。
回答by Amber
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.
对我来说，这看起来像 unix 文件权限模式（755= rwxr-xr-x，644= rw-r--r--） - 旧模式包括 +x （可执行）标志，新模式没有。
This msysgit issue's repliessuggests setting core.filemode to false in order to get rid of the issue:
这个 msysgit 问题的回复建议将 core.filemode 设置为 false 以摆脱这个问题：
git config core.filemode false
回答by NovelX
Setting core.filemodeto false does work, but make sure the settings in ~/.gitconfigaren't being overridden by those in .git/config.
设置core.filemode为false的工作，但要确保在设置~/.gitconfig不会被那些覆盖.git/config。
回答by Scott Willeke
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):
我在从旧硬盘驱动器复制带有工作文件的 git repo 时遇到过这个问题。问题源于所有者和权限从旧驱动器/机器更改为新驱动器/机器这一事实。总而言之，运行以下命令来解决问题（感谢这个超级用户的回答）：
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:
前一个命令实际上会解决 git diff 报告的差异，但会取消您列出目录的能力，因此ls ./失败ls: .: Permission denied. 要解决这个问题：
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 .shscripts, you'll need to revert those. You can do that with the following command for each file:
坏消息是，如果您确实有任何要保持可执行的文件，例如.sh脚本，则需要还原这些文件。您可以使用以下命令为每个文件执行此操作：
chmod +x ./build.sh # where build.sh is the file you want to make executable again
回答by K. Symbol
Usually happens when the repo is cloned between Windows and Linux/Unix machines.
通常在 Windows 和 Linux/Unix 机器之间克隆 repo 时发生。
Just tell git to ignore filemode change, here are several ways:
只需告诉 git 忽略文件模式更改，这里有几种方法：
Config ONLY for current repo:
git config core.filemode falseConfig globally:
git config --global core.filemode falseAdd in ~/.gitconfig:
[core] filemode = false
仅为当前存储库配置：
git config core.filemode false全局配置：
git config --global core.filemode false在 ~/.gitconfig 中添加：
[core] filemode = false
Just select one of them.
只需选择其中之一。
回答by SuperNova
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 .
回答by Doppelganger
You could try git reset --hard HEAD to reset the repo to the expected default state.
您可以尝试 git reset --hard HEAD 将 repo 重置为预期的默认状态。
回答by bkm
I have faced the same issue. And this save my life: https://gist.github.com/jtdp/5443498
我遇到了同样的问题。这救了我的命：https: //gist.github.com/jtdp/5443498
git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never \
| git apply`
回答by Wae
You can use the following command to change your file mode back.
git add --chmod=+x -- filenameThen commit to the branch.
您可以使用以下命令将文件模式改回。
git add --chmod=+x -- filename然后提交到分支。
回答by IskandarG
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.
相反，对于未设置为可执行文件并且由于上述操作而更改的文件。有一个更好的方法来做到这一点，但这只是一个非常快速和肮脏的修复。
回答by Collin Krawll
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.
我在将我的分支与 master 进行比较时遇到了这个问题。当我希望我的分支与 master 分支相同时，Git 返回了一个“模式”错误。我通过删除文件然后再次合并主文件来修复。
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 diffreturned no differences between my-branch and master.
在此之后，git diff返回 my-branch 和 master 之间没有差异。
