ostrzeżenie: LF zostanie zastąpione przez CRLF.
W zależności od używanego edytora, plik tekstowy z LF nie musiałby być zapisywany za pomocą CRLF: ostatni redaktorzy mogą zachować styl eol. Ale to ustawienie konfiguracji git nalega na zmianę tych ...
Po prostu upewnij się, że (tak jak tutaj polecam ):
git config --global core.autocrlf false
W ten sposób unikniesz jakiejkolwiek automatycznej transformacji i nadal możesz określić je za pomocą .gitattributespliku i core.eoldyrektyw .
windows git "LF zostanie zastąpiony przez CRLF"
Czy to ostrzeżenie jest cofnięte?
Nie: korzystasz z systemu Windows i git configstrona pomocy wspomina
Użyj tego ustawienia, jeśli chcesz mieć CRLFzakończenia wierszy w katalogu roboczym, nawet jeśli repozytorium nie ma znormalizowanych zakończeń wierszy.
Jak opisano w " git zastępując LF przez CRLF ", powinno to występować tylko przy pobieraniu (nie zatwierdzaniu), z core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
Jak wspomniano w Xiaopeng jest odpowiedź , że ostrzeżenie jest taka sama, jak:
ostrzeżenie: (Jeśli sprawdzisz go / lub sklonujesz do innego folderu z aktualną core.autocrlfkonfiguracją,) LF zostanie zastąpiony przez CRLF
Plik będzie miał oryginalne zakończenia linii w Twoim (bieżącym) katalogu roboczym.
Jak wspomniano w git-for-windows/gitnumerze 1242 :
Nadal uważam, że ta wiadomość jest myląca, można ją rozszerzyć, aby zawierała lepsze wyjaśnienie problemu, na przykład: „LF zostanie zastąpiony przez CRLF file.jsonpo usunięciu pliku i ponownym sprawdzeniu”.
Uwaga: Git 2.19 (wrzesień 2018), przy zastosowaniu core.autocrlf, podrobiony „LF zostaną zastąpione przez CRLF” Ostrzeżenie jest teraz stłumione .
Jak słusznie zauważa quaylar , jeśli po zatwierdzeniu następuje konwersja, to tylko.LF
To ostrzeżenie „ LF will be replaced by CRLF” pochodzi z funkcji 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);
Jest nazywany przez convert.c#crlf_to_git(), sam przez convert.c#convert_to_git()siebie nazywany convert.c#renormalize_buffer().
A to ostatnie renormalize_buffer()jest wywoływane tylko przez merge-recursive.c#blob_unchanged().
Podejrzewam więc, że ta konwersja ma miejsce git committylko wtedy, gdy wspomniane zatwierdzenie jest częścią procesu scalania.
Uwaga: w przypadku Git 2.17 (drugi kwartał 2018 r.) Czyszczenie kodu dodaje pewne wyjaśnienia.
Zob. Commit 8462ff4 (13 stycznia 2018) autorstwa Torsten Bögershausen ( tboegi) .
(Scalone przez Junio C Hamano - gitster- w zatwierdzeniu 9bc89b1 , 13 lutego 2018 r.)
convert_to_git (): safe_crlf /CheckSafe staje się int conv_flags
Dzwoniąc convert_to_git()The checksafeparametr definiuje co powinno się zdarzyć, jeżeli przeliczenie EOL ( CRLF --> LF --> CRLF) nie obie strony czysto.
Ponadto zdefiniowano również, czy zakończenia linii powinny być renormalizowane ( CRLF --> LF), czy pozostawione bez zmian.
CheckSafe było safe_crlfwyliczeniem z następującymi wartościami:
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
Zauważ, że regresja wprowadzona w 8462ff4 („ convert_to_git():
safe_crlf/checksafestaje się int conv_flags”, 2018-01-13, Git 2.17.0) z powrotem w cyklu Git 2.17 spowodowała, że autocrlfprzepisanie spowodowało wyświetlenie komunikatu ostrzegawczego
pomimo ustawieniasafecrlf=false .
Zobacz zatwierdzenie 6cb0912 (4 czerwca 2018) autorstwa Anthony'ego Sottile'a ( asottile) .
(Scalone przez Junio C Hamano - gitster- w zobowiązaniu 8063ff9 , 28 czerwca 2018 r.)
