在VSCode中，我有这样一个弹出窗口：
warning: LF will be replaced by CRLF in <xxx>
我以为这是个警告，但我的承诺没有通过。我检查并尝试在VSCode中找到一个配置GIT的位置。我读到了一些建议，如：
git config --get core.autocrlf
我试图在VSCode设置中找到一些选项，但我就是找不到在VSCode中配置此选项的方法。正确的配置方法是什么？非常感谢。
z18hc3ub1#
在VSCode之外，git config --global core.autocrlf false是一个很好的选择，因为I mentioned here。在VSCode中，确保EOL（行尾）指示器（状态栏右下角）是正确的。如果您的文件有混合行尾，则没有option to opt out of line ending normalisation for files，这意味着在保存使用VS代码编辑的文件时，它似乎会自动执行行尾标准化，而不会通知用户任何类型。注：警告消息随Git 2.37 (Q3 2022)变化，变为：
git config --global core.autocrlf false
In the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it.
5lhxktic2#
如果你在Windows上工作，你需要决定你的沙盒中需要什么样的行尾，以及你的存储库中需要什么样的行尾。autocrlf设置的“正确”选择并不对每个人都一样。
autocrlf
如果你只是不想让Git弄乱行尾，那么@VonC的答案是正确的--autocrlf设置为false意味着将文件原封不动地传入和传出Git。这可以说是autocrlf的唯一正确设置，因为正如@VonC所指出的，像Windows .bat文件这样的文件会被换行符转换打断，而且您也不希望在二进制文件中发生行尾转换（如果您不小心对.jpg文件进行了CRLF-〉LF转换，那么该文件可能无法恢复...）
false
然而，我在Windows上的通常回答是不同的：在我的repos中，我总是想要Unix风格的换行符。但是在我的Windows机器上，一些讨厌的工具创建带有Windows风格换行符的文件。是的，你可以（并且应该）设置您的编辑器使用正确的行尾，但是一个设置为input的autocrlf抓住了我的“错误”，例如，当一个文件是由Windows机器上的Python脚本生成时，在我的Windows配置中，我总是使用git config --global core.autocrlf input，这意味着我的文件总是用Unix风格的换行符提交，但它们会被 checkout ，因为它们存在于repo中。那么.bat和二进制文件呢？当这个设置导致转换时，Git会向我发出警告，所以如果它发生在一个不应该发生转换的文件上，我会收到一个警告，并可以修复该提交的情况。然而，我不记得曾经遇到过这样的问题，但我的Git repos几乎是完全可移植的源代码和文本文件，我真的真的希望LF结尾。如果您正在Windows PC上处理面向Linux或Mac的项目，我认为这是一个很好的设置。
input
git config --global core.autocrlf input
我提到这一点是为了完整性，但通常建议不要这样做。如果你总是希望你的文件在你工作的时候有CRLF行结束，设置autocrlf为true可以做到这一点，但提交他们在Unix风格的LF行结束。这在某些情况下是有意义的，但在许多情况下可能会导致麻烦。
true
从你收到的消息来看，我猜true是你的设置，所以你可能想决定false和input中哪一个最适合你，然后在Git Bash提示符下运行以下两个命令之一，全局地设置它：
或
我真正想要的是autocrlf=prompt设置：问我什么时候我试图提交一个文件在它的CRLF做。我想我应该使自己一个预提交挂钩...
autocrlf=prompt
rdlzhqv93#
如果您使用的是Windows修复方法是使用autocrlf true
除非您删除并再次克隆repos或重新启动索引
ltskdhd14#
在VS代码中，你会在屏幕右下方看到一个显示“LF”的行结束（EOL）指示符，点击它，屏幕顶部会弹出一个选择（在那里你可以选择解释器等），你可以按照这个网站上的描述修改那里的值：https：//dev.to/wagslane/如何使代码中的换行符保持一致lf vs-crlf-2c 3 p #：~：text=快速修复& text =在%20的%20底部%20右侧%20处，有%20正确%20的%20换行符。
4条答案
按热度按时间z18hc3ub1#
在VSCode之外，
git config --global core.autocrlf false是一个很好的选择，因为I mentioned here。在VSCode中，确保EOL（行尾）指示器（状态栏右下角）是正确的。
如果您的文件有混合行尾，则没有option to opt out of line ending normalisation for files，这意味着在保存使用VS代码编辑的文件时，它似乎会自动执行行尾标准化，而不会通知用户任何类型。
注：警告消息随Git 2.37 (Q3 2022)变化，变为：
5lhxktic2#
如果你在Windows上工作，你需要决定你的沙盒中需要什么样的行尾，以及你的存储库中需要什么样的行尾。
autocrlf设置的“正确”选择并不对每个人都一样。自动创建=假：别乱动我的文件！
如果你只是不想让Git弄乱行尾，那么@VonC的答案是正确的--
autocrlf设置为false意味着将文件原封不动地传入和传出Git。这可以说是
autocrlf的唯一正确设置，因为正如@VonC所指出的，像Windows .bat文件这样的文件会被换行符转换打断，而且您也不希望在二进制文件中发生行尾转换（如果您不小心对.jpg文件进行了CRLF-〉LF转换，那么该文件可能无法恢复...）autocrlf=输入：在创建文件时修复错误
然而，我在Windows上的通常回答是不同的：在我的repos中，我总是想要Unix风格的换行符。但是在我的Windows机器上，一些讨厌的工具创建带有Windows风格换行符的文件。是的，你可以（并且应该）设置您的编辑器使用正确的行尾，但是一个设置为
input的autocrlf抓住了我的“错误”，例如，当一个文件是由Windows机器上的Python脚本生成时，在我的Windows配置中，我总是使用git config --global core.autocrlf input，这意味着我的文件总是用Unix风格的换行符提交，但它们会被 checkout ，因为它们存在于repo中。那么.bat和二进制文件呢？当这个设置导致转换时，Git会向我发出警告，所以如果它发生在一个不应该发生转换的文件上，我会收到一个警告，并可以修复该提交的情况。然而，我不记得曾经遇到过这样的问题，但我的Git repos几乎是完全可移植的源代码和文本文件，我真的真的希望LF结尾。
如果您正在Windows PC上处理面向Linux或Mac的项目，我认为这是一个很好的设置。
自动创建=真：我确实希望在 checkout 的文件中始终包含CRLF
我提到这一点是为了完整性，但通常建议不要这样做。如果你总是希望你的文件在你工作的时候有CRLF行结束，设置
autocrlf为true可以做到这一点，但提交他们在Unix风格的LF行结束。这在某些情况下是有意义的，但在许多情况下可能会导致麻烦。做出选择并全局保存
从你收到的消息来看，我猜
true是你的设置，所以你可能想决定false和input中哪一个最适合你，然后在Git Bash提示符下运行以下两个命令之一，全局地设置它：或
Git开发人员的愿望清单：
我真正想要的是
autocrlf=prompt设置：问我什么时候我试图提交一个文件在它的CRLF做。我想我应该使自己一个预提交挂钩...rdlzhqv93#
如果您使用的是Windows
修复方法是使用autocrlf true
git配置--全局核心。autocrlf为真
除非您删除并再次克隆repos或重新启动索引
git add --重新规范化。
ltskdhd14#
在VS代码中，你会在屏幕右下方看到一个显示“LF”的行结束（EOL）指示符，点击它，屏幕顶部会弹出一个选择（在那里你可以选择解释器等），你可以按照这个网站上的描述修改那里的值：https：//dev.to/wagslane/如何使代码中的换行符保持一致lf vs-crlf-2c 3 p #：~：text=快速修复& text =在%20的%20底部%20右侧%20处，有%20正确%20的%20换行符。