在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:

LF将被CRLF取代

这种转变的后果是什么?


当前回答

它应该是:

警告:(如果你检出/或克隆到另一个文件夹与你当前的核心。如果为true,)LF将被CRLF所取代 该文件将在您的(当前)工作目录中有其原始的行结束符。

这张图可以解释它的意思。

其他回答

在notepad++中打开文件。 进入菜单编辑→EOL转换。 单击Windows格式。 保存文件。

我不太了解Windows上的Git,但是……

在我看来,Git正在转换返回格式以匹配正在运行的平台(Windows)。CRLF是Windows上的默认返回格式,而LF是大多数其他操作系统的默认返回格式。

当代码被移动到另一个系统时,返回格式可能会得到适当的调整。我还认为Git足够聪明,可以保持二进制文件的完整性,而不是试图在JPEG文件中将lf转换为crlf。

总而言之,您可能不需要为这种转换担心太多。但是,如果您将项目归档为tarball,其他编码员可能会喜欢使用LF行终止符而不是CRLF。取决于你有多关心(取决于你不使用记事本),你可能想要设置Git使用LF返回,如果你可以的话:)

附录:CR为ASCII码13,LF为ASCII码10。因此,CRLF是两个字节,而LF是一个字节。

如何使Git忽略不同的行结束

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/(不工作)

您可以完全禁用CRLF行为,或者通过更改.gitattributes文件中的条目来禁用每个文件类型。在我的例子中,我写的是: crlf 这告诉Git忽略所有文件的行结束符。并且不会更改工作目录中的文件。即使你有核心。自专制设置为true, false或输入。

echo "* -crlf" > .gitattributes

在单独提交时执行此操作,否则当您进行单个更改时,Git可能仍然会看到整个文件被修改(取决于您是否更改了selflf选项)。

这个真的有用。Git将尊重混合行结束项目中的行结束符,而不会就此警告您。

在两个不同的操作系统(Linux和Windows)中使用“代码”时,CRLF可能会导致一些问题。

我的Python脚本是在Linux Docker容器中编写的,然后使用Windows的Git Bash推送。它给了我LF将被CRLF取代的警告。我并没有想太多,但当我后来开始写剧本时,它说:

/usr/bin/env: 'python\r':没有这样的文件或目录

现在这个r对你们来说是ramification的意思。Windows在“\n”上方使用“CR”-换行符- \n\r。这是你可能需要考虑的事情。

从~/。gitattributes文件,

* text = auto

将防止Git首先检查行结束符。