git autocrlf 设置设置为 true 但在暂存文件、提交和签出时出现意外结果

Question

我已经阅读了很多关于配置设置 core.autocrlf 以及您可以设置它的内容。然而，我在理解为什么它不能按我预期的方式工作时遇到了很多问题。

• 我正在使用的机器： Windows
• git经验：初学者
• 终端： git bash
• core.autocrlf：真

所以让我们从第一个困惑开始。我在工作目录中使用了命令echo hello > file1.txt，然后我还通过打开记事本创建了一个文本文件，并将其保存在与“file1.txt”相同的位置，并将其命名为“file_windows.txt”。在记事本上打开这两个文件时，我看到了不同之处，“file1.txt”在记事本选项卡的底部标记了“Unix (LF)”，而“file_windows.txt”标记为“Windows (CRLF)”。我想这是因为第一个文件是使用 unix/linux 命令创建的，而另一个文件是通过使用记事本和 windows 创建的。

现在，当我尝试将这些文件添加到暂存区时，问题就出现了。在使用命令git add file1.txt时，我遇到了以下消息：

warning: LF will be replaced by CRLF in file1.txt.
The file will have its original line endings in your working directory

我有点震惊，因为我认为将 core.autocrlf 设置为 true 意味着 git 会通过确保在添加到暂存区域时将“crlf”替换为“lf”来更改文件，而不是警告建议的其他方式，当然，启用该设置的目的是，例如，如果在 linux 平台上将 core.autocrlf 设置为 false 的某人，将能够使用该 git 存储库而不必担心关于某些具有“crlf”而不是“lf”的文件。

然后，当使用命令git add file_windows.txt 时，不会出现预期的警告，因为我想它正在做它应该做的事情，并且在将它添加到暂存区域时将“crlf”替换为“lf”。我想在这里得到的是，如果由于某种原因我正在使用的文件位于“lf”中，我不希望它然后在我添加时将其切换为“crlf”它到集结区，因为真的没有必要这样做，而且可能没有好处。

另一件要提的是（虽然不应该太认真，因为我是使用 git 的初学者，所以我不知道是不是因为我做错了什么）当我提交两个文件时，然后使用命令git checkout <commit hash> 然后通过start file1.txt 打开文件（在记事本上打开它们），我最终没有看到警告所说的更改，它仍然显示为“Unix（LF） " 而不是 "c​​rlf" 所以这让我更加困惑。

谁能解释一下这是怎么回事？

Answer 1

警告“LF will be replace by CRLF in file1.txt”表示下次检出文件时它将被 CRLF 替换。该文件确实以 LF 结尾存储在存储库中，因为所有受文本处理的文件都以这种方式存储。

但是，当您使用 git checkout 时，Git 不会检出索引中的最新文件。这就是为什么您看不到 git checkout 修改工作树中的文件的原因。

此消息最终是无害的，但它只是警告您已将一个文件放入工作树中，该文件不使用您请求的行尾，无论是显式还是隐式，这意味着您最终可能会得到不同的下次克隆或签出存储库时的行为。如果您的所有工具都能优雅地处理任何行尾，或者您已正确配置 .gitattributes 文件以指定适当的行尾，那么您不必担心。