git status 显示修改，git checkout -- <file> 不会删除它们

git status shows modifications, git checkout -- <file> doesn't remove them

提问by rbellamy

I would like to remove all changes to my working copy.
Running git statusshows files modified.
Nothing I do seems to remove these modifications.
E.g.:

我想删除对我的工作副本的所有更改。
运行git status显示文件已修改。
我所做的一切似乎都无法消除这些修改。
例如：

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

采纳答案by Ikke

There are multiple problems the can cause this behaviour:

有多种问题可能导致这种行为：

Line ending normalization

行尾归一化

I've had these kinds of problems too. It comes down to git automatically converting crlf to lf. This is typically caused by mixed line endings in a single file. The file gets normalized in the index, but when git then denormalizes it again to diff it against the file in the working tree, the result is different.

我也遇到过这样的问题。归结为 git 自动将 crlf 转换为 lf。这通常是由单个文件中的混合行尾引起的。该文件在索引中被规范化，但是当 git 然后再次对其进行非规范化以将其与工作树中的文件进行比较时，结果是不同的。

But if you want to fix this, you should disable core.autocrlf, change all line endings to lf, and then enable it again. Or you can disable it altogether by doing:

但是如果你想解决这个问题，你应该禁用core.autocrlf，将所有行结尾更改为 lf，然后再次启用它。或者您可以通过执行以下操作完全禁用它：

git config --global core.autocrlf false

Instead of core.autocrlf, you can also consider using .gitattributefiles. This way, you can make sure everyone using the repo uses the same normalization rules, preventing mixed line endings getting into the repository.

除了core.autocrlf，您还可以考虑使用.gitattribute文件。这样，您可以确保使用 repo 的每个人都使用相同的规范化规则，防止混合行尾进入存储库。

Also consider setting core.safecrlfto warn if you want git to warn you when a non-reversible normalization would be performed.

如果您希望 git 在执行不可逆规范化时发出警告，还可以考虑将core.safecrlf设置为警告。

The git manpagessay this:

git联机帮助页是这样说的：

CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.

CRLF 转换可能会损坏数据。autocrlf=true 将在提交期间将 CRLF 转换为 LF，在结帐期间将 LF 转换为 CRLF。git 无法重新创建在提交之前包含 LF 和 CRLF 混合的文件。对于文本文件，这是正确的做法：它更正行尾，以便我们在存储库中只有 LF 行尾。但是对于意外分类为文本的二进制文件，转换可能会损坏数据。

Case-insensitive file systems

不区分大小写的文件系统

On case-insensitive filesystems, when the same filename with different casing is in the repository, git tries to checkout both, but only one ends up on the file system. When git tries to compare the second one, it would compare it to the wrong file.

在不区分大小写的文件系统上，当存储库中具有不同大小写的相同文件名时，git 会尝试检出两者，但最终只有一个出现在文件系统上。当 git 尝试比较第二个时，它会将其与错误的文件进行比较。

The solution would either be switching to a non-case insensitive filesystem, but this in most cases is not feasible or renaming and committing one of the files on another filesystem.

解决方案要么切换到不区分大小写的文件系统，但这在大多数情况下是不可行的，或者重命名并提交另一个文件系统上的一个文件。

回答by Rian Sanderson

I was having this problem on Windows but wasn't prepared to look into the ramifications of using config --global core.autocrlf falseI also wasn't prepared to abandon other private branches and goodies in my stash and start with a fresh clone. I just need to get something done. Now.

我在 Windows 上遇到了这个问题，但不准备研究使用的后果config --global core.autocrlf false我也不准备放弃我藏匿处的其他私人分支和好东西，并从一个新的克隆开始。我只需要完成一些事情。现在。

This worked for me, on the idea that you let git rewrite your working directory completely:

这对我有用，因为你让 git 完全重写你的工作目录：

git rm --cached -r .
git reset --hard

(Note that running just git reset --hardwasn't good enough nor was a plain rmon the files before the resetas are suggested in the comments to the original question)

（请注意，在原始问题的评论中建议的那样，运行git reset --hard还不够好rm，文件上的内容也不简单reset）

回答by zebediah49

Another solution that may work for people, since none of the text options worked for me:

另一个可能适用于人们的解决方案，因为没有一个文本选项对我有用：

1. Replace the content of .gitattributeswith a single line: * binary. This tells git to treat every file as a binary file that it can't do anything with.
2. Check that message for the offending files is gone; if it's not you can git checkout -- <files>to restore them to the repository version
3. git checkout -- .gitattributesto restore the .gitattributesfile to its initial state
4. Check that the files are still not marked as changed.

1. 用.gitattributes一行替换 的内容：* binary。这告诉 git 将每个文件都视为它无法执行任何操作的二进制文件。
2. 检查违规文件的消息是否消失；如果不是，您可以git checkout -- <files>将它们恢复到存储库版本
3. git checkout -- .gitattributes将.gitattributes文件恢复到其初始状态
4. 检查文件是否仍未标记为已更改。

回答by Marty Neal

For future people having this problem: Having filemode changes can also have the same symptoms. git config core.filemode falsewill fix it.

对于将来遇到此问题的人：更改文件模式也可能具有相同的症状。 git config core.filemode false将修复它。

回答by Richard Lalancette

This has been driving me crazy, especially that I couldn`t fix this without any of the solutions found online. Here is how I solved it. Can't take the credits here since this is the work of a colleague :)

这让我发疯了，尤其是如果没有在网上找到任何解决方案，我就无法解决这个问题。这是我解决它的方法。由于这是同事的工作，因此无法在这里获得学分:)

Source of the problem: My initial installation of git was without auto line conversion on windows. This caused my initial commit to GLFW to be without the proper line ending.

问题的根源：我最初安装的 git 在 Windows 上没有自动行转换。这导致我最初对 GLFW 的承诺没有正确的行尾。

Note: This is only a local solution. The next guy cloning the repo will still be stuck with this problem. A permanent solution can be found here: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

注意：这只是本地解决方案。下一个克隆 repo 的人仍然会遇到这个问题。可以在此处找到永久解决方案：https: //help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository。

Setup: Xubuntu 12.04 Git repo with glfw project

设置：Xubuntu 12.04 Git repo with glfw 项目

Problem: Unable to reset glfw files. They always show as modified, regardless of what I tried.

问题：无法重置 glfw 文件。无论我尝试什么，它们总是显示为已修改。

Solved:

解决了：

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

回答by moo moo

I had a .bat file with the same problem (couldn't get rid it it in untracked files). git checkout -- didn't work, neither did any of the suggestions on this page. The only thing that worked for me was to do:

我有一个 .bat 文件有同样的问题（无法在未跟踪的文件中摆脱它）。git checkout -- 没有用，这个页面上的任何建议也没有用。唯一对我有用的是：

git stash save --keep-index

And then to delete the stash:

然后删除存储：

git stash drop

回答by Fam Wired

Got the same issue twice! Both times when stash some changes I made and then tried to pop them back. Could'nt pop the changes since I've got lots of file that are changed -- but they are NOT! They are EXACTLY the same.

两次遇到同样的问题！两次都隐藏了我所做的一些更改，然后尝试将它们弹出。无法弹出更改，因为我有很多文件已更改 - 但它们不是！它们完全相同。

I now think I've tried all the above solutions without success. After trying the

我现在想我已经尝试了所有上述解决方案，但都没有成功。尝试之后

git rm --cached -r .
git reset --hard

I now got almost all the files in my repository modified.

我现在修改了存储库中的几乎所有文件。

When diffing the file, it says I've deleted all the lines and then add them again.

比较文件时，它说我已删除所有行，然后再次添加它们。

Kind of disturbing. I will now avoid stashing in the future..

有点令人不安。我现在将避免在未来藏匿..

The only solution is to clone a new repository and start over. (Made it last time)

唯一的解决方案是克隆一个新的存储库并重新开始。（上次做的）

回答by nsg

Try doing a

尝试做一个

git checkout -f

git 结帐 -f

That should clear all the changes in the current working local repo

这应该清除当前工作本地存储库中的所有更改

回答by Artfunkel

I was only able to fix this by temporary deleting my repo's .gitattributes file (which defined * text=autoand *.c text).

我只能通过临时删除我的 repo 的 .gitattributes 文件（定义了* text=auto和*.c text）来解决这个问题。

I ran git statusafter deleting and the modifications were gone. They didn't return even after .gitattributes was put back in place.

我git status删除后运行，修改消失了。即使将 .gitattributes 放回原位，它们也没有返回。

回答by dpiskyulev

Having consistent line endings is a good thing. For example it will not trigger unnecessary merges, albeit trivial. I have seen Visual Studio create files with mixed line endings.

拥有一致的行尾是一件好事。例如，它不会触发不必要的合并，尽管是微不足道的。我见过 Visual Studio 创建带有混合行尾的文件。

Also some programs like bash (on linux) do require that .sh files are LF terminated.

还有一些像 bash（在 linux 上）这样的程序确实要求 .sh 文件以 LF 终止。

To make sure this happens you can use gitattributes. It works on repository level no matter what the value of autcrlf is.

为了确保发生这种情况，您可以使用 gitattributes。无论 autcrlf 的值是多少，它都适用于存储库级别。

For example you can have .gitattributes like this: * text=auto

例如你可以有这样的 .gitattributes：* text=auto

You can also be more specific per file type/extension if it did matter in your case.

如果在您的情况下确实很重要，您还可以针对每个文件类型/扩展名进行更具体的说明。

Then autocrlf can convert line endings for Windows programs locally.

然后 autocrlf 可以在本地转换 Windows 程序的行尾。

On a mixed C#/C++/Java/Ruby/R, Windows/Linux project this is working well. No issues so far.

在混合 C#/C++/Java/Ruby/R、Windows/Linux 项目中，这运行良好。到目前为止没有问题。