【问题标题】：git status shows modifications even with autocrlf=falsegit status 显示修改，即使 autocrlf=false
【发布时间】：2012-06-15 20:50:17
【问题描述】：

我遇到了与这个问题相同的问题：git status shows modifications, git checkout -- <file> doesn't remove them

Git 继续显示工作目录修改，即使是 git config --global core.autocrlf false：

E:\_dev\github\Core [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

（请注意，我什至将--system 设置为false）

为什么看起来 Git 仍在修改我的行尾？

尝试摆脱修改

基线

E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

git checkout -- .

E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed) 
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

有时这会以一种奇怪的方式产生影响：

E:\_dev\github\Core [master +0 ~628 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~361 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:\_dev\github\Core [master +0 ~93 -0]> git reset --hard
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master
E:\_dev\github\Core [master +0 ~93 -0]>

git 添加 .;混帐藏匿； git stash 删除

E:\_dev\github\Core [master +0 ~93 -0]> git add .
... warnings ....
warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt.
The file will have its original line endings in your working directory.

E:\_dev\github\Core [master +0 ~93 -0]> git stash
Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from 
RemiBou/master
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master

E:\_dev\github\Core [master +0 ~93 -0]> git stash drop
Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:\_dev\github\Core [master +0 ~93 -0]> git status .\tools\StatLight\StatLight.EULA.txt
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

【问题讨论】：

我有这个问题here - 他们很可能是同一个问题。在我的问题中，我还验证了没有 gitattributes 干扰。
@djechlin 你能把git config -l 的输出放在一个pastebin 中并链接到这里吗？并确保您的项目根目录或任何其他文件夹中没有 .gitattributes。

标签： git revert git-status core.autocrlf

【解决方案1】：

这似乎确实是 msysgit 中的一个错误。作为一种解决方法，请尝试创建一个 .gitattributes 文件，其中包含

* -text

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

【讨论】：

似乎该错误不仅限于 msysgit。可以在 Mac OS X 上轻松重现：stackoverflow.com/questions/22823004/…
看了几十篇关于 git 和行尾的 stackoverflow 帖子后，这是救了我的一篇！

【解决方案2】：

检查你是否没有.gitattributes文件

正如"Effect" section of the gitattributes man page中提到的，这些文件也可以对eol和自动转换产生影响：

text ^^^^^^

此属性启用和控制行尾标准化。
当一个文本文件被规范化时，它的行尾在存储库中被转换为LF。
要控制工作目录中使用的行尾样式，请对单个文件使用 eol 属性，对所有文本文件使用 core.eol 配置变量。

还要检查core.eol 的配置，如“How line ending conversions work with git core.autocrlf between different operating systems”中所述。

【讨论】：

在存储库或工作目录中没有.gitattributes，在我的个人资料中也没有。 core.eol 未设置；将其依次设置为{ 'lf', 'crlf', 'native' } 中的所有 3 个，并且在每种情况下，git checkout -- . 修改后的文件仍然存在，并且结帐时会出现“警告：LF 将被 CRLF 替换”。
@codekaizen 好的。想法是不设置任何core.eol 或.gitattributes text 指令，并将auto.crlf 保留为false。如果这仍然无法阻止 eol 转换，那么我们可以消除这些并继续寻找。
感谢您的详细信息。鉴于未设置core.eol，并且问题仍然存在；我别无选择，只能尝试设置它并确定它是否至少修改了结果，以便深入了解 git 坚持更改行尾的原因。
对此有任何跟进吗？或解决方法？如果使用 autocrlf = false 它仍然坚持转换文件（似乎行结尾不一致的文件），这似乎是 git/mysgit 某处的错误。
同样的问题已经好几天了，还没有找到可行的解决方案？

【解决方案3】：

我正在调查 MSysGit 中 core.autocrlf 的奇怪行为，我发现有：

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

在全局配置文件和从另一台 PC 复制的 repo 中的 NO core.autocrlf 设置（未克隆，仅复制），发出 git status 命令会导致所有文本文件标记为已修改（周围没有 git 属性）。

但是如果你添加一个本地（存储库）core.autocrlf 设置为 true，然后发出 git status 命令，所有更改都会消失并且存储库变回干净。

但是（这是奇怪的行为）如果您从存储库配置文件中删除刚刚添加的 core.autocrlf 设置（从而返回到确切的初始状态），git status 命令继续报告没有更改！

鉴于尚未对存储库执行任何操作，仅更改配置设置并恢复到原始状态就可以了...

如果这不是错误，我无法想象世界上谁能称这是“正常”行为。

【讨论】：

【解决方案4】：

这个问题可能是gitattributes' text option.引起的

请仔细阅读文档，但基本上autocrlf 仅在text 未在.gitattributes 中设置时才重要：

未指定
如果未指定 text 属性，git 使用 core.autocrlf 配置变量来确定是否应该转换文件。

通过以下方式查找您的 .gitattributes 文件：

find <root-dir> -name .gitattributes

还有grep 用于text、eol 或crlf，以找出罪魁祸首并根据需要进行修改。

您可以只更改此文件并恢复更改，而无需提交足够长的时间来解决您的问题。

【讨论】：

【解决方案5】：

“autocrlf”问题是 ~~cross~~ 多平台 repo 的典型问题（即在 linux 下的服务器上与 tortoisegit 使用 samba 共享）

我意识到，有时（通常）这更像是一个“chmod”问题而不是 autocrlf 问题： - git 状态窗口显示待修改 - git status linux 什么都不显示

"模式改变 100755 => 100644 config/packager.xml"

检查您的“静态”文件是否不是 +x，（在这种情况下，tortoisegit 不会喜欢它）

【讨论】：

已确认，我也曾在 windows 上使用 cygwin git 看到这一点。

【解决方案6】：

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

警告！要格外小心，先做好备份；这可能具有很强的破坏性。

如果您关心的所有数据都已提交到存储库中，您可以简单地删除工作目录中的所有内容（当然除了隐藏的 .git 目录）并运行 git reset --hard HEAD 以重新创建 git工作目录仅来自存储库数据。

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

【讨论】：

假设没有未跟踪的文件，为什么除了 git reset --hard 之外还有其他影响？
@djechlin 因为 git 没有跟踪它曾经在已签出的文件中具有不同的 eol 设置。这已经在几个安装中观察到，其中 core.eol 和 core.autocrlf 设置已为现有文件动态更改。如果 git reset --hard 认为不需要，它不会做任何事情。
这个建议对我不起作用。删除所有内容，执行 git reset --hard HEAD，仍然看到文件已修改。