如何删除显示“旧模式 100755 新模式 100644”的文件 来自 Git 中未暂存的更改？
出于某种原因，当我最初从存储库中为我的 git 项目进行拉取时， 我的工作副本中有大量文件没有进行明显的更改，但不断出现在我的未暂存更改区域中。
我在 Windows xp 上使用 Git Gui，当我查看文件以查看发生了什么变化时。 我只看到：
old mode 100755
new mode 100644
有人知道这意味着什么吗？
如何将这些文件从未暂存的更改列表中取出？ （非常烦人的是必须浏览 100 个文件，只是为了挑选出我最近编辑过并想要提交的文件）。
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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（19）
对我来说，这看起来像unix文件权限模式（
755=rwxr-xr-x，644=rw-r--r --) - 旧模式包含+x（可执行）标志，新模式则不包含。此 msysgit 问题的回复建议将 core.filemode 设置为 false 以获得摆脱问题：
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:
将
core.filemode设置为 false 确实有效，但请确保~/.gitconfig中的设置不会被.git/config中的设置覆盖代码>.要确定 core.filemode 设置的来源，请从存储库的根文件夹（或根目录下的任何文件夹）运行以下命令（适用于任何操作系统）：
git config --show-origin --show-scope --get-all core.filemode
Setting
core.filemodeto false does work, but make sure the settings in~/.gitconfigaren't being overridden by those in.git/config.To know for sure where the
core.filemodesetting 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当在 Windows 和 Linux/Unix 机器之间克隆存储库时，通常会发生这种情况。
只需告诉 git 忽略文件模式更改即可。 以下是执行此操作的几种方法：
仅针对当前存储库进行配置：
全局配置：
在~/.gitconfig中添加：
<前><代码> [核心]
文件模式=假
只需选择其中之一即可。
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:
Config globally:
Add in ~/.gitconfig:
Just select one of them.
我在从旧硬盘驱动器复制带有工作文件的 git 存储库时遇到过这个问题几次。 该问题源于所有者和权限从旧驱动器/机器更改为新驱动器/机器这一事实。 总而言之，运行以下命令来解决问题（感谢这个超级用户的回答）
：命令实际上会解决 git diff 报告的差异，但会撤销您列出目录的能力，因此
ls ./会失败，并显示ls: .: Permission returned。 解决这个问题：坏消息是，如果您确实有任何想要保持可执行的文件（例如
.sh脚本），则需要恢复这些文件。 您可以对每个文件使用以下命令来执行此操作：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):
The former command will actually resolve the differences that git diff reported, but will revoke your ability to list the directories, so
ls ./fails withls: .: Permission denied. To fix that: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:我也遇到过同样的问题。 这救了我的命：
这会将所有权限恢复为差异的权限，这样你就什么都没有了，只剩下你对文件所做的更改。
https://gist.github.com/jtdp/5443498
更多详细信息请参见https://stackoverflow.com/a/4408378/450383
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
More details in https://stackoverflow.com/a/4408378/450383
这对我有用：
This worked for me:
设置 git config core.filemode false 的公认答案有效，但会产生后果。 将 core.filemode 设置为 false 告诉 git 忽略文件系统上的任何可执行位更改，因此它不会将此视为更改。 如果您确实需要在将来随时对此存储库进行可执行位更改，则必须手动执行此操作，或者将 core.filemode 设置回 true。
如果所有修改的文件都应具有模式 100755，则一个不太重要的替代方案是执行类似的操作，
仅精确更改模式，不多也不少，没有其他影响。
（就我而言，这是由于 OneDrive 与 MacOS 上的文件系统同步所致；通过不更改 core.filemode，我保留了将来可能再次发生模式更改的可能性；就我而言，我想知道它是否再次发生，并且更改 core.filemode 会将其隐藏起来，这是我不希望的）
The accepted answer to set
git config core.filemode false, works, but with consequences. Settingcore.filemodeto 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 setcore.filemodeback to true.A less consequential alternative, if all the modified files should have mode 100755, is to do something like
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 changingcore.filemodewill hide it from me, which I don't want)此解决方案会将 git 文件权限从 100755 更改为 100644，并将更改推送回 bitbucket 远程存储库。
查看您的存储库的文件权限：
git ls-files --stage如果 100755 而您想要 100644
然后运行此命令：
git ls-files --stage | git ls-files --stage | git ls-files --stage | git ls-files --stage | git ls-files --stage | sed 's/\t/ /g' | sed 's/\t/ /g' | 切 -d' ' -f4 | xargs git update-index --chmod=-x
现在再次检查您的存储库的文件权限：
git ls-files --stage现在提交您的更改：
This solution will change the git file permissions from 100755 to 100644 and push changes back to the bitbucket remote repo.
Take a look at your repo's file permissions:
git ls-files --stageIf 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=-xNow check your repo's file permissions again:
git ls-files --stageNow commit your changes:
看来您更改了目录的某些权限。 我执行了以下步骤来恢复它。
It seems you have changed some permissions of the directory. I did the following steps to restore it.
当您拉取并且所有文件在远程存储库中均可执行时，就会发生这种情况。 使它们再次可执行将使一切再次恢复正常。
您可能需要执行以下操作：
相反，对于未设置为可执行文件且因上述操作而更改的文件。 有一个更好的方法可以做到这一点，但这只是一个非常快速和肮脏的修复。
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.
You might need to do:
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.
你可以尝试
git重置——硬头
将存储库重置为预期的默认状态。
You could try
git reset --hard HEAD
to reset the repo to the expected default state.
这与 bkm 发现的类似，但它也考虑了所有已删除的文件，并且仅在应用更改时发出警告。
这可以很好地恢复之前提交的文件模式设置。
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.
如果有任何已删除的文件，上述许多解决方案都会失败。
这将列出仅修改但未删除的文件，并将它们全部更改为
755A 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执行这个命令：
chmod 755 xxx将“xxx”替换为文件的路径，然后希望一切顺利。 该命令将权限级别从 100644 设置回 100755
Execute this command:
chmod 755 xxxreplace "xxx" with the path of the file, then hopefully things will go right. The command set the priviledge level back from 100644 to 100755
我只有一个麻烦的文件，其权限已更改。手动删除它，然后进行签出以提取新副本。
要单独回滚它，我只需使用 rm
幸运的是我还没有上演它。
如果我有的话，我可以在运行
git checkout --之前运行git reset --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 runninggit checkout -- <file>您可以使用以下命令将文件模式更改回来。
git add --chmod=+x -- 文件名
然后提交到分支。
You can use the following command to change your file mode back.
git add --chmod=+x -- filenameThen commit to the branch.
如果您在 Linux devcontainer 中的 Windows 中进行开发，使用相同的 Windows 和 WSL 版本的文件夹，您可能需要执行以下步骤：
在本地存储库范围中取消设置文件模式（即，从内部运行此命令存储库文件夹层次结构）：
git config --unset --local core.fileMode在 Windows 中，将文件模式设置为 false在全局范围内（即从 Windows 中的任何位置运行）：
git config --global core.filemode false在容器中，将 filemode 设置为 true在全局范围内（即从 Linux 容器中的任何位置运行）：
git config --global core.filemode true现在您将看不到修改后的文件没有任何文件内容更改。
此外，您可能需要在 devcontainer.json 文件的
postCreateCommand选项中进行此更改，以便在重建容器时它仍然存在。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:
Unset the filemode in local repo scope (i.e., run this command from within the repo folder hierarchy):
git config --unset --local core.fileModeIn Windows, set the filemode to false at the global scope (i.e., run from anywhere in Windows):
git config --global core.filemode falseIn 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 trueNow 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
postCreateCommandoption so that it persists when the container is rebuilt.我刚刚在将我的分支与 master 进行比较时遇到了这个问题。 当我期望我的分支与 master 相同时，Git 返回了一个“模式”错误。 我通过删除文件然后再次合并 master 来修复。
首先我运行了 diff：
返回：
然后运行以下命令来修复：
此后， git diff 返回 my-branch 和 master 之间没有差异。
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:
This returned:
I then ran the following to fix:
After this,
git diffreturned no differences between my-branch and master.从 WSL2 运行 git 以获得完全的 Linux 兼容性，然后无需在提交前后翻转 core.filemode 之类的解决方法。
Run git from WSL2 for full Linux compatibility then there is no need for workarounds like flipping core.filemode before and after a commit.