Windows git „ostrzeżenie: LF zostanie zastąpiony przez CRLF”, czy to ostrzeżenie jest cofnięte?

env:

• System Windows 7
• msysgit

Wheng I git commit, mówi:

warning: LF will be replaced by CRLF. 

Czy ten ostrzegawczy ogon jest cofnięty?
Edytuję plik w systemie Windows, koniec linii wygląda CRLFtak, jak na tym zdjęciu:

I git zmienia go na, LFaby zatwierdzić repozytorium.
Więc myślę, że prawidłowe ostrzeżenie to:

warning: CRLF will be replaced by LF. 

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.)}

TAK, ostrzeżenie jest wstecz.

W rzeczywistości nie powinno to być nawet ostrzeżeniem. Ponieważ całe to ostrzeżenie mówi (ale niestety wstecz) to, że znaki CRLF w twoim pliku z końcami linii Windows zostaną zastąpione znakami LF przy zatwierdzeniu. Co oznacza, że ​​jest znormalizowany do tych samych końcówek linii, które są używane przez * nix i MacOS.

Nic dziwnego się nie dzieje, jest to dokładnie takie zachowanie, jakiego normalnie byś chciał.

To ostrzeżenie w swojej obecnej formie to jedna z dwóch rzeczy:

1. Niefortunny błąd połączony z nadmiernie ostrożnym komunikatem ostrzegawczym lub
2. Bardzo sprytny spisek, który sprawi, że naprawdę to przemyślisz ...

;)

- Aktualizacja 9 lipca ---

Usunięto „Jest poprawny i dokładny”, jak skomentował @mgiuca

======

NIE . NIE jest to rozmowa o twoich plikach aktualnie z CRLF. Zamiast tego mówi o plikach z rozszerzeniem LF.

Powinien brzmieć:

ostrzeżenie: ( Jeśli to sprawdzisz / lub sklonujesz do innego folderu z obecną konfiguracją core.autocrlf ,) LF zostanie zastąpiony przez CRLF

Plik będzie miał oryginalne zakończenia linii w Twoim ( bieżącym ) katalogu roboczym.

To zdjęcie powinno wyjaśniać, co to znaczy.

Wszystko to zakłada core.autocrlf=true

Oryginalny błąd:

ostrzeżenie: LF zostanie zastąpiony przez CRLF
Plik będzie miał oryginalne zakończenia linii w katalogu roboczym.

Jaki błąd POWINIENEŚ przeczytać:

ostrzeżenie: LF zostanie zastąpiony przez CRLF w twoim katalogu roboczym
Plik będzie miał oryginalne zakończenia linii LF w repozytorium git

Wyjaśnienie tutaj :

Efektem ubocznym tej wygodnej konwersji i właśnie o tym jest ostrzeżenie, które widzisz, jest to, że jeśli plik tekstowy, którego jesteś autorem, miał zakończenia LF zamiast CRLF, będzie przechowywany z LF jak zwykle, ale po zaznaczeniu później będzie miał zakończenia CRLF. W przypadku zwykłych plików tekstowych jest to zwykle w porządku. W tym przypadku ostrzeżenie jest „dla twojej informacji”, ale w przypadku, gdy git nieprawidłowo oceni plik binarny jako plik tekstowy, jest to ważne ostrzeżenie, ponieważ git może wtedy uszkodzić twój plik binarny.

Zasadniczo plik lokalny, który był poprzednio LF, będzie teraz miał lokalnie CRLF

git config --global core.autocrlf false działa dobrze w przypadku ustawień globalnych.

Ale jeśli korzystasz z Visual Studio, może być również konieczne zmodyfikowanie .gitattributesdla niektórych typów projektów ( np. Aplikacja biblioteki klas C # ):

• usuń linię * text=auto

Po ustawieniu core.autocrlf=trueotrzymywałem "LF zostanie zastąpiony przez CRLF" (uwaga nie "CRLF zostanie zastąpiony przez LF") kiedy edytowałem git add(a może to było git commit?) Pliki w oknach w repozytorium (które używa LF), który został sprawdzony przed ustawieniem core.autocrlf=true.

Zrobiłem nowe zakupy z core.autocrlf=truei teraz nie otrzymuję tych wiadomości.

Jeśli korzystasz z programu Visual Studio 2017, 2019, możesz:

1. otwórz główny .gitignore (zaktualizuj lub usuń inne pliki .gitignore w innych projektach w rozwiązaniu)
2. wklej poniższy kod:

[core]
 autocrlf = false
[filter "lfs"]
 required = true
 clean = git-lfs clean -- %f
 smudge = git-lfs smudge -- %f
 process = git-lfs filter-process

Zrób tylko prostą rzecz:

1. Otwórz git-hub (Shell) i przejdź do katalogu, do którego należy plik (cd / a / b / c / ...)
2. Uruchom dos2unix (czasami dos2unix.exe)
3. Spróbuj zatwierdzić teraz. Jeśli ponownie pojawi się ten sam błąd. Wykonaj wszystkie powyższe kroki z wyjątkiem zamiast dos2unix, wykonaj unix2dox (czasami unix2dos.exe)