虽然我不知道是什么导致了这种奇怪的行为，但我知道还有一种方法可以丢弃可能有效的更改。

**警告！**请务必小心，先做好备份;这可能是高度破坏性的。

• 如果你关心的所有数据都提交到仓库中 *，你可以简单地删除工作目录中的所有内容（当然除了隐藏的.git目录），然后运行git reset --hard HEAD让git只从仓库数据重新创建工作目录。

在执行此操作之前，请记住仔细检查是否没有任何git未跟踪的重要数据。仅仅检查git status是否有未提交的更改是不够的--记住，从工作目录中删除所有文件也会删除你告诉git忽略的文件，而且它们不会被git reset --hard HEAD重新创建，因为它们根本没有被跟踪。

这看起来确实像是msysgit中的一个bug。作为解决方法，请尝试创建一个.gitattributes文件，其中包含

* -text

这将告诉git不要对任何文件执行EOL转换。

检查是否没有.gitattributes文件
如gitattributes手册页的“Effect”部分所述，这些文件也会对eol和自动转换产生影响：

text ^^^^^^

此属性启用并控制行尾规范化。
当一个文本文件被规范化时，它的行尾在存储库中被转换为LF。
要控制工作目录中使用的行结束样式，请对单个文件使用eol属性，对所有文本文件使用core.eol配置变量。
还请检查core.eol的配置，如“在不同操作系统之间如何使用git core.autocrlf进行行结束转换”中所述。
Git 2.41（Q2 2023）包含一个文档更新，以澄清文本和eol属性如何交互以指定行尾转换。
参见commit 6696077（2023年5月2日）通过Alex Henrie ( alexhenrie )。
（由Junio C Hamano -- gitster --合并于commit c05615e，2023年5月10日）

docs：重写text和eol属性的文档

协助人：Torsten Bögershausen
签字人：亚历克斯·亨利
这两个句子很容易混淆，因为text属性的描述听起来和text=auto属性的描述完全一样：
“在路径上设置text属性将启用行尾规范化”
当文本设置为“自动”时，路径将标记为自动行尾转换
除非读者已经熟悉这两种变体，否则他们很可能会认为“行尾规范化”与“自动行尾转换”是一回事。
同样不清楚的是，text=auto段落中的短语“当文件已使用CRLF提交时，不进行转换”是否同样适用于前面描述的纯文本属性。
此外，它错误地暗示只有在提交文件时才会抑制规范化。
实际上，在CRLF文件上运行git add（man），向文件添加text=auto属性，然后再次运行git add，也不会对行尾做任何处理。
最重要的是，在eol属性的文档中，有几处听起来像是它不影响签入时的规范化，或者它强制签入时的规范化。
这听起来也像是需要设置eol（或设置一个配置变量）来打开 checkout 时的转换，但是如果没有指定eol，text属性可以自己打开 checkout 时的转换。
重新表述text、text=auto、eol、eol=crlf和eol=lf的文档，以便清楚地了解它们是如何相同的、如何不同的以及在什么情况下执行转换。
gitattributes现在在其手册页中包括：
此属性将路径标记为文本文件，从而启用行尾转换：当一个匹配的文件被添加到索引中时，文件的行尾在索引中被规范化为LF。相反，当文件从索引复制到工作目录时，它的行尾可能会从LF转换为CRLF，具体取决于eol属性、Git配置和平台（请参阅下面对eol的解释）。
gitattributes现在在其手册页中包括：
在签入和 checkout 时的转换，如上所述。每次文件被检入时，行结束符都会在索引中被规范化为LF，即使该文件之前是以CRLF行结束符添加到Git的。
gitattributes现在在其手册页中包括：
当text设置为“auto”时，Git会自行决定文件是文本还是二进制。如果文件是文本，并且Git中没有CRLF结尾，则在签入和 checkout 时转换行尾，如上所述。否则，在签入或 checkout 时不进行转换。
gitattributes现在在其手册页中包括：
此属性标记一个路径，以便在工作树检出时在工作树中使用特定的行尾样式。只有在设置了text或text=auto时才有效（见上文），但如果未指定text，则指定eol会自动设置text。
gitattributes现在在其手册页中包括：
此设置在文件检出时将工作目录中文件的行尾转换为CRLF。
gitattributes现在在其手册页中包括：
此设置在工作目录中使用与文件检出时索引中相同的行结束符。

Unspecified

如果未指定文件的eol属性，则其在工作目录中的行尾由core.autocrlf或core.eol配置变量确定（请参阅git config中这些选项的定义）。如果设置了text，但这两个变量都没有设置，则默认值在Windows上为eol=crlf，在所有其他平台上为eol=lf。

我正在研究MSysGit中core.autocrlf的奇怪行为，我发现：

[core]
    autocrlf = false
    safecrlf = true
    ignorecase = true
    eol = native

在全局配置文件和NO core.autocrlf 设置中，从另一台PC复制的存储库中（不是克隆的，只是复制的），发出git status命令会导致所有文本文件标记为已修改（周围没有gitattributes）。
但是如果你添加一个local（repository）core.autocrlf 设置为true，然后发出一个git status命令，所有的更改都会消失，仓库恢复为干净的。
但是（这是一个奇怪的行为）如果你从仓库配置文件中删除了刚刚添加的core.autocrlf设置（从而返回到确切的初始状态），git status命令仍然没有报告任何更改！
假设没有对存储库执行任何操作，那么只需要更改配置设置并恢复到原始状态就可以了……
如果这不是一个bug，我无法想象世界上有谁能称之为“正常”行为。

此问题可能由gitattributes' text option.引起
请仔细阅读文档，但本质上autocrlf只在.gitattributes中没有设置text时才有意义：
未指明
如果text属性未指定，git将使用core.autocrlf配置变量来决定是否转换文件。
通过以下方式查找您的.gitattributes文件：

find <root-dir> -name .gitattributes

和grep为text，eol或crlf找到你的罪魁祸首，并根据需要修改。
您可以只更改此文件并恢复更改，而无需提交足够长的时间来解决问题。

“autocrlf”问题是跨多平台存储库的典型问题（即，在Linux下的服务器上使用带有tortoisegit的桑巴舞共享）
我意识到，有时（通常），这更像是一个“chmod”问题，而不是一个autocrlf问题：- git status windows display pending modifications - git status linux display nothing
“模式更改100755 => 100644 config/packager.xml”
检查你的“静态”文件不是+x，（在这种情况下tortoisegit不会喜欢它）