即使使用 autocrlf=false git status 也会显示修改

git status shows modifications even with autocrlf=false

提问by codekaizen

I'm experiencing the same issues as in this question: git status shows modifications, git checkout -- <file> doesn't remove them

我遇到了与此问题相同的问题：git status 显示修改， git checkout -- <file> 不会删除它们

Git continues to show working directory modifications, even with git config --global core.autocrlf false:

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

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

(Note that I've even set the --systemsetting to be false)

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

Why does it appear that Git is still modifying my end of lines?

为什么 Git 似乎仍在修改我的行尾？

Attempts to get rid of modifications

试图摆脱修改

Baseline

基线

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 -- .

git 结帐 -- 。

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")

Occasionally this will have an effect in an odd way:

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

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

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 add .; git stash; git stash drop

git 添加.; git 藏匿处；git 藏匿处

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")

采纳答案by Brecht Machiels

This seems like a bug in msysgit indeed. As a workaround, try creating a .gitattributesfile containing

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

* -text

This will tell git not to perform EOL conversions on any files.

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

回答by VonC

Check if you have no .gitattributesfile

检查您是否没有.gitattributes文件

As mentioned in the "Effect" section of the gitattributesman page, those files can also have an effect on eol and automatic transformation:

正如手册页的“效果”部分所述gitattributes，这些文件也可以对 eol 和自动转换产生影响：

text ^^^^^^

This attribute enables and controls end-of-line normalization.
When a text file is normalized, its line endings are converted to LFin the repository.
To control what line ending style is used in the working directory, use the eol attribute for a single file and the core.eolconfiguration variable for all text files.

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

Check also your config for core.eol, as mentioned in "How line ending conversions work with git core.autocrlfbetween different operating systems".

还要检查您的配置core.eol，如“行尾转换如何git core.autocrlf在不同操作系统之间工作”中所述。

回答by nexbit

I'm investigating the weird behavior of core.autocrlf in MSysGit, and I found that having:

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

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

in the global config file and NO core.autocrlfsetting in a repo copied from another PC (not cloned, only copied), issuing a git statuscommand results in ALL text files marked as modified (no gitattributes around).

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

But if you add a local (repository) core.autocrlfsetting to true, and then issue a git statuscommand, all the changes disappears and the repository turns back to be clean.

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

BUT (and this is the strange behavior) if you remove the just added core.autocrlf setting from the repository config file (thus returning to the exact initial state), the git status command continues to report no changes!

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

Given that no operations has been performed on the repository, only changing a config setting, and reverting back to the original state, has done the trick...

鉴于没有对存储库执行任何操作，仅更改配置设置并恢复到原始状态，就完成了……

If this isn't a bug, I can't imagine who in the world can call this a "normal" behavior.

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

回答by Cris Favero

This problem can be caused by gitattributes' text option.

这个问题可能是由gitattributes 的 text 选项引起的。

Please read the documentation carefully but essentially autocrlfonly matters if textis not set in a .gitattributes:

请仔细阅读文档，但基本上autocrlf只有在text未设置的情况下才重要.gitattributes：

Unspecified
If the text attribute is unspecified, git uses the core.autocrlf configuration variable to determine if the file should be converted.

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

Find your .gitattributesfile via:

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

find <root-dir> -name .gitattributes

And grepfor text, eolor crlfto find your culprit and revise as necessary.

并且grep为了text，eol或者crlf找到你的罪魁祸首并根据需要进行修改。

You may just change this file and revert the change without committing for long enough to get through your issue.

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

回答by 131

"autocrlf" issue is a typical issue for crossmulti platform repo (i.e. using a samba share with tortoisegit over a server under linux)

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

I realized, that sometimes (often), it's more a "chmod" issue than a autocrlf one : - git status windows display pending modifications - git status linux display nothing

我意识到，有时（通常），这更像是一个“chmod”问题而不是 autocrlf 问题：- git status 窗口显示挂起的修改- git status linux 不显示任何内容

"mode change 100755 => 100644 config/packager.xml"

“模式更改 100755 => 100644 config/packager.xml”

Check that your "static" files are not +x, (and in this case tortoisegit wont like it)

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

回答by Jan Warcho?

Although i don't know what is causing this weird behaviour, i know one more way of discarding changes that might work.

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

Warning!Be extremely careful and do a backup first; this can be highly destructive.

警告！要非常小心并先进行备份；这可能是极具破坏性的。

If all data that you care about is committed in the repository, you can simply delete everything in your working directory (of course except hidden .git directory) and run git reset --hard HEADto have git recreate the working directory solely from the repository data.

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

Remember to carefully check if you don't have any important data that is not tracked by git before doing this. It's not enough to check git statusfor uncommitted changes - remember that deleting all files from the working dir will also delete files which you told git to ignore, and they won't be recreated with git reset --hard HEADbecause they're not tracked at all.

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