我在 Windows 上并且禁用了 core.autocrlf:

$ git config core.autocrlf; git config --global core.autocrlf
false
false

现在，我假设 git 不会弄乱任何行尾，但我的存储库中的某些文件不断导致问题。

我刚刚克隆了一个新的 repo 副本，git 已经告诉我有未暂存的更改。当我 git diff -R 时，我可以看到 CRLF 行结尾已添加到文件中:

diff --git b/nginx-1.11.1/contrib/geo2nginx.pl a/nginx-1.11.1/contrib/geo2nginx.pl
index bc8af46..29243ec 100644
--- b/nginx-1.11.1/contrib/geo2nginx.pl
+++ a/nginx-1.11.1/contrib/geo2nginx.pl
@@ -1,58 +1,58 @@
-#!/usr/bin/perl -w
-
-# (c) Andrei Nigmatulin, 2005
+#!/usr/bin/perl -w^M
+^M
+# (c) Andrei Nigmatulin, 2005^M

我不明白这些行尾是从哪里来的，但我也无法“还原”此更改。当我再次 checkout 文件时，它仍然会在之后被修改:

$ git checkout -f nginx-1.11.1/contrib/geo2nginx.pl
$ git status
On branch dev
Your branch is up-to-date with 'origin/dev'.
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:   nginx-1.11.1/contrib/geo2nginx.pl

no changes added to commit (use "git add" and/or "git commit -a")

这对我来说毫无意义，所以我只是在文件上运行 dos2unix:

$ dos2unix nginx-1.11.1/contrib/geo2nginx.pl
dos2unix: converting file nginx-1.11.1/contrib/geo2nginx.pl to Unix format...

现在应该不会有什么变化了吧？但是该文件在 git status 中仍显示为已修改，并且 git diff 仍会在工作副本中报告 CRLF 行结尾。

当我现在暂存并提交文件时，生成的文件将具有 LF 行结尾，即使 diff 显示 CRLF 行结尾。

我没有全局 .gitattributes(git config --global core.attributesfile 不输出任何内容)。项目中的 .gitattributes 设置了 * text eol=lf ( full .gitattributes )。

这是怎么回事，我该如何解决？

重现问题

我可以用开源重现这个问题 project I'm maintaining :

$ git clone git@github.com:fairmanager/fm-log.git
Cloning into 'fm-log'...
remote: Counting objects: 790, done.
remote: Total 790 (delta 0), reused 0 (delta 0), pack-reused 790
Receiving objects: 100% (790/790), 201.71 KiB | 138.00 KiB/s, done.
Resolving deltas: 100% (418/418), done.
Checking connectivity... done.

$ cd fm-log/
$ git status
On branch master
Your branch is up-to-date with 'origin/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:   .idea/dictionaries/OliverSalzburg.xml
        modified:   .idea/inspectionProfiles/Project_Default.xml
        modified:   .idea/inspectionProfiles/profiles_settings.xml

no changes added to commit (use "git add" and/or "git commit -a")

最佳答案

有趣:对于新添加到问题的 repo ，我尝试克隆它，并且在 BSD 上看到相同的东西:

$ git clone git@github.com:fairmanager/fm-log.git
Cloning into 'fm-log'...
remote: Counting objects: 790, done.
remote: Total 790 (delta 0), reused 0 (delta 0), pack-reused 790
Receiving objects: 100% (790/790), 201.71 KiB | 0 bytes/s, done.
Resolving deltas: 100% (418/418), done.
Checking connectivity... done.
$ cd fm-log/
$ git status
On branch master
Your branch is up-to-date with 'origin/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:   .idea/dictionaries/OliverSalzburg.xml
    modified:   .idea/inspectionProfiles/Project_Default.xml
    modified:   .idea/inspectionProfiles/profiles_settings.xml

no changes added to commit (use "git add" and/or "git commit -a")

试着看看发生了什么:

$ git diff
warning: CRLF will be replaced by LF in .idea/dictionaries/OliverSalzburg.xml.
[snip]

似乎 HEAD:.idea/ 文件实际上有回车符(最后一行没有换行符，因此提示符紧跟在右尖括号之后):

$ git show HEAD:.idea/dictionaries/OliverSalzburg.xml | vis
<component name="ProjectDictionaryState">\^M
  <dictionary name="OliverSalzburg">\^M
    <words>\^M
      <w>colorizer</w>\^M
      <w>multiline</w>\^M
    </words>\^M
  </dictionary>\^M
</component>$ 

工作树版本同样有回车符(没有剪切和粘贴，但 vis 显示相同的 \^M 行结尾)。

所以至少在这种情况下发生的是由于 .gitattributes 设置:

$ head -2 .gitattributes 
# In general, use LF for text
* text eol=lf

Git 将在提交期间将这些文件转换为仅 LF，而 HEAD 版本包含 CR-LF 结尾。这就是 git status 在这里所说的。

在 .gitattributes 中注释掉 * text eol=lf 会使状态消失(因为文件不会被转换)，当然 .gitattributes 现在标记为已修改。有趣的是，再次将属性行放回去，状态完全消失了:必须强制 git checkout 替换工作树版本才能恢复状态(例如，手动 rm -rf .idea 并再次检查，或 git reset --hard).

(大概——我在这里有点猜测——当 Git 注意到工作树和 HEAD 版本不同时，索引条目在 git checkout 期间被特别标记。这使得 Git 仔细检查文件. 修改 .gitattributes 并通过 git status 运行内部差异可能会取消标记索引条目。这部分纯属推测，旨在解释 git 的奇怪行为状态...)

关于windows - 为什么 git 总是弄乱我的行尾？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39076854/