aviso: LF será substituído por CRLF.
Dependendo do editor que você estiver usando, não será necessário salvar um arquivo de texto com LF com o CRLF: editores recentes podem preservar o estilo eol. Mas essa configuração do git insiste em mudar esses ...
Basta certificar-se de que (como eu recomendo aqui ):
git config --global core.autocrlf false
Dessa forma, você evita qualquer transformação automática e ainda pode especificá-las através de um .gitattributesarquivo e core.eoldiretivas .
windows git "LF será substituído por CRLF"
Este aviso está atrasado?
Não: você está no Windows e a git configpágina de ajuda menciona
Use essa configuração se desejar ter CRLFterminações de linha em seu diretório de trabalho, mesmo que o repositório não possua finalizações de linha normalizadas.
Conforme descrito em " git substituindo LF por CRLF ", ele deve ocorrer apenas no checkout (não confirmado), por core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
Conforme mencionado na Xiaopeng 's resposta , esse aviso é o mesmo que:
aviso: (Se você fizer check-out / ou clonar em outra pasta com a sua core.autocrlfconfiguração atual ), o LF será substituído pelo CRLF.
O arquivo terá suas terminações de linha originais no diretório de trabalho (atual).
Como mencionado na git-for-windows/gitedição 1242 :
Ainda sinto que esta mensagem é confusa, a mensagem pode ser estendida para incluir uma explicação melhor do problema, por exemplo: "LF será substituído pelo CRLF file.jsonapós remover o arquivo e fazer check-out novamente".
Nota: Git 2.19 (setembro de 2018), ao usar core.autocrlf, o aviso falso "LF será substituído por CRLF" agora é suprimido .
Como o quaylar comenta corretamente , se houver uma conversão no commit, é LFsomente.
Esse aviso específico " LF will be replaced by CRLF" vem de 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);
É chamado por convert.c#crlf_to_git(), ele mesmo chamado convert.c#convert_to_git(), ele mesmo chamado por convert.c#renormalize_buffer().
E esse último renormalize_buffer()é chamado apenas por merge-recursive.c#blob_unchanged().
Portanto, suspeito que essa conversão ocorra git commitsomente se o referido commit fizer parte de um processo de mesclagem.
Nota: com o Git 2.17 (Q2 2018), uma limpeza de código adiciona alguma explicação.
Veja commit 8462ff4 (13 Jan 2018) por Torsten Bögershausen ( tboegi) .
(Incorporado por Junio C Hamano - gitster- in commit 9bc89b1 , 13 de fevereiro de 2018)
convert_to_git (): safe_crlf / checksafe torna-se int conv_flags
Ao chamar convert_to_git(), o checksafeparâmetro definiu o que deveria acontecer se a conversão de EOL ( CRLF --> LF --> CRLF) não fizesse uma ida e volta limpa.
Além disso, também definiu se as terminações de linha devem ser renormalizadas ( CRLF --> LF) ou mantidas como estão.
checksafe era um safe_crlfenum com estes valores:
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
Observe que uma regressão introduzida em 8462ff4 (" convert_to_git(): safe_crlf/checksafetorna -
se int conv_flags", 13/01/2018, Git 2.17.0) no ciclo Git 2.17 fez com que as autocrlfreescritas produzissem uma mensagem de aviso,
apesar da configuraçãosafecrlf=false .
Veja commit 6cb0912 (04 Jun 2018) por Anthony Sottile ( asottile) .
(Incorporado por Junio C Hamano - gitster- in commit 8063ff9 , 28 de junho de 2018)
