Windows git"警告:LF将被CRLF取代",是警告尾巴落后了吗？
ENV:
- Windows 7的
- msysgit
我git commit说,它说:
warning: LF will be replaced by CRLF.
这个警告尾巴落后了吗？
我在Windows中编辑文件,行尾是CRLF,就像这张图:
并且git将其更改LF为承诺回购.
所以我认为正确的警告是:
warning: CRLF will be replaced by LF.
Von*_*onC 156
警告:LF将被CRLF取代.
根据您使用的编辑器,使用LF的文本文件无需与CRLF一起保存:最近的编辑器可以保留 eol样式.但是那个git配置设置坚持要改变那些......
只需确保(我在这里推荐):
git config --global core.autocrlf false
这样,您可以避免任何自动转换,并且仍然可以通过.gitattributes文件和core.eol指令指定它们.
windows git"LF将被CRLF取代"
这个警告尾巴是否落后？
否:您在Windows上,git config帮助页面确实提到了
如果要
CRLF在工作目录中包含行结尾,请使用此设置,即使存储库没有标准化的行结尾.
如" git用CRLF替换LF "中所描述的那样,它应该仅在结账时(不提交)发生core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
警告:(如果您使用当前
core.autocrlf配置检出/或克隆到另一个文件夹,)LF将被CRLF替换.
该文件将在您的(当前)工作目录中具有其原始行结尾.
我仍然觉得这个消息令人困惑,可以扩展消息以包含对问题的更好解释,例如:"
file.json在删除文件并再次检出文件后,LF将被CRLF取代".
注意:Git 2.19(2018年9月),使用时core.autocrlf,伪造的"LF将被CRLF替换"警告现在被禁止.
正如quaylar正确评论的那样,如果提交转换,则LF仅限于.
该特定警告" LF will be replaced by CRLF"来自convert.c#check_safe_crlf():
if (checksafe == SAFE_CRLF_WARN)
warning("LF will be replaced by CRLF in %s.
The file will have its original line endings
in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
die("LF would be replaced by CRLF in %s", path);
它被称为convert.c#crlf_to_git(),本身称为convert.c#convert_to_git(),被称为convert.c#renormalize_buffer().
而最后一个renormalize_buffer()只被称为merge-recursive.c#blob_unchanged().
所以我怀疑git commit只有当所述提交是合并过程的一部分时才会发生转换.
注意:使用Git 2.17(2018年第二季度),代码清理会增加一些解释.
见提交8462ff4(2018年1月13日)由托斯滕Bögershausen( )tboegi.
(由Junio C gitsterHamano合并- -在提交9bc89b1,2018年2月13日)
convert_to_git():safe_crlf/checksafe成为int conv_flags
调用时
convert_to_git(),checksafe参数定义了如果EOL conversion(CRLF --> LF --> CRLF)没有干净地往返的情况会发生什么.
此外,它还定义了行结尾是否应该重新规范化(CRLF --> LF)或保持原样.checksafe是一个
safe_crlf具有以下值的枚举:
SAFE_CRLF_FALSE: do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL: die in case of EOL roundtrip errors
SAFE_CRLF_WARN: print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF: keep all line endings as they are
请注意,在Git 2.17循环中,8462ff4(" convert_to_git():
safe_crlf/checksafe变成int conv_flags",2018-01-13,Git 2.17.0)中引入的回归导致autocrlf重写产生警告消息,
尽管设置safecrlf=false.
见Anthony Sottile()提交6cb0912(2018年6月4日).(由Junio C Hamano合并- -在提交8063ff9,2018年6月28日)asottile
gitster
- @VonC我必须承认我没有得到它.Git-Book声明_Git可以通过在提交时自动将CRLF行结尾转换为LF来处理这个问题,反之亦然,当它将代码签出到您的文件系统时.这意味着在**commit**上会有转换为**LF**,永远不要**CRLF**.这意味着上述警告不正确.拥有`core.autocrlf = true`将**总是**在repo中的LF和工作树imho中的CRLF(即使在非Windows下).资料来源:[link](http://git-scm.com/book/ch7-1.html#Formatting-and-Whitespace) (14认同)
- "这个警告尾部是否向后？它应该只在结账时出现"我在**提交**上看到了这个确切的警告.所以**是**,它是落后的.它向后触发我搜索这个.很高兴其他人也注意到了!真正阅读这些警告的人看到它会在提交消息上转换为CRLF,这是非常令人困惑的. (12认同)
- "因此,我怀疑只有当所述提交是合并过程的一部分时,才会在git提交中进行此转换." 不.我在常规提交中看到了这一点. (7认同)
- 令我烦恼的是，该消息会突然弹出。为什么需要警告git会完全按照我配置的去做。我不需要警告，“嘿，我们仍在像您要求的那样为您转换行尾”。当系统按设计运行时，它不应发出不必要的警告，否则人们会在无关紧要的消息中错过重要的警告。 (2认同)
Sti*_*itt 23
是的警告是倒退的.
事实上,它首先应该不是警告.因为所有这些警告都说(但不幸的是倒退)是带有Windows行结尾的文件中的CRLF字符将在提交时替换为LF.这意味着它被标准化为*nix和MacOS使用的相同行结尾.
没有什么奇怪的事情发生,这正是你通常想要的行为.
它当前形式的警告是两件事之一:
- 一个不幸的错误加上过于谨慎的警告信息,或者
- 一个非常聪明的情节让你真正想到这一点......
;)
Xia*_*com 17
不.这是正确和准确的.它不是在讨论你目前使用的文件CRLF.而是用文件来讨论文件LF.
它应该是:
警告:( 如果您使用当前的core.autocrlf配置检出/或克隆到另一个文件夹,)LF将被CRLF取代
该文件将在(当前)工作目录中具有其原始行结尾.
这张照片应该解释它的含义.
- 我认为这是唯一正确的答案。 (2认同)
mik*_*kew 12
所有这一切都假设了 core.autocrlf=true
原始错误:
警告:LF将被CRLF替换
该文件将在您的工作目录中具有其原始行结尾.
错误应该读什么:
警告:LF将在工作目录中被CRLF替换.
该文件将在git存储库中具有其原始LF行结尾
这里的解释:
这个方便转换的副作用,这就是你所看到的警告,就是如果你最初创作的文本文件有LF结尾而不是CRLF,它将像往常一样用LF存储,但是当检查时以后它会有CRLF结局.对于普通文本文件,这通常很好.在这种情况下,警告是"为了您的信息",但是如果git错误地将二进制文件评估为文本文件,那么这是一个重要的警告,因为git会破坏您的二进制文件.
基本上,以前LF的本地文件现在将在本地具有CRLF
avp*_*avp 10
发生这种情况是因为 Windows 上的 GitHub Desktop 配置假定使用 CRLF，但文本编辑器可能使用 LF。您可以更改本地存储库设置来lf代替使用。
导航到 git 存储库的根目录并以完全相同的顺序执行此操作
git config core.eol lf
git config core.autocrlf input
git config --global core.autocrlf false 适用于全局设置。
但是，如果您使用的是Visual Studio，则可能还需要修改.gitattributes某些类型的项目（例如c＃类库应用程序）：
- 删除线
* text=auto
| 归档时间： |
|
| 查看次数： |
169546 次 |
| 最近记录： |