git zastępuje LF przez CRLF

Uruchamianie gita na komputerze z systemem Windows XP za pomocą bash. Wyeksportowałem swój projekt z SVN, a następnie sklonowałem nagie repozytorium.

Następnie wkleiłem eksport do katalogu nagich repozytoriów i zrobiłem:

git add -A

Następnie dostałem listę wiadomości z informacją:

LF zostanie zastąpiony przez CRLF

Jakie są konsekwencje tego nawrócenia? To rozwiązanie .NET w Visual Studio.

Te komunikaty są spowodowane nieprawidłową wartością domyślną core.autocrlfw systemie Windows.

Koncepcja autocrlfpolega na transparentnym przetwarzaniu konwersji zakończeń linii. I robi to!

Zła wiadomość : wartość należy skonfigurować ręcznie.
Dobra wiadomość : należy to zrobić JEDEN czas na instalację gita (możliwe jest również ustawienie projektu).

Jak autocrlfdziała :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Tutaj crlf= marker końca linii w stylu win = = styl lfuniksowy (i Mac OSX).

( crnie wpływa na pre-osx dla żadnej z trzech powyższych opcji)

Kiedy pojawia się to ostrzeżenie (w systemie Windows)

    - autocrlf= truejeśli masz styl uniksowy lfw jednym ze swoich plików (= RZADKO),
    - autocrlf= inputjeśli masz styl wygrywający crlfw jednym ze swoich plików (= prawie ZAWSZE),
    - autocrlf= false- NIGDY!

Co oznacza to ostrzeżenie

Ostrzeżenie „ LF zostanie zastąpione przez CRLF ” mówi, że (mając autocrlf= true) stracisz swój LF w stylu uniksowym po cyklu sprawdzania zmian (zostanie zastąpiony przez CRLF w stylu Windows). Git nie oczekuje, że użyjesz LF w stylu uniksowym pod Windows.

Ostrzeżenie „ CRLF zostanie zastąpione przez LF ” mówi, że (mając autocrlf= input) stracisz swój CRLF w stylu Windows po cyklu sprawdzania zmian (zostanie zastąpiony przez LF w stylu unixowym). Nie używaj inputpod oknami.

Jeszcze inny sposób pokazania, jak autocrlfdziała

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

gdzie x to CRLF (styl Windows) lub LF (styl unix), a strzałki oznaczają

file to commit -> repository -> checked out file

Jak naprawić

Wartość domyślna dla core.autocrlfjest wybierana podczas instalacji gita i przechowywana w ogólnosystemowej gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig). Są też (kaskadowanie w następującej kolejności):

   - „globalny” (na użytkownika) gitconfig w ~/.gitconfig, jeszcze inny
   - „globalny” (na użytkownika) gitconfig w $XDG_CONFIG_HOME/git/configlub    - $HOME/.config/git/configi
„lokalny” (na repo) gitconfig .git/configw działającym katalogu.

Napisz więc git config core.autocrlfdziałający katalog, aby sprawdzić aktualnie używaną wartość i

   - dodaj autocrlf=falsedo całego systemu gitconfig # rozwiązanie dla systemu
   - git config --global core.autocrlf false            # rozwiązanie dla użytkownika
   - git config --local core.autocrlf false              # rozwiązanie dla projektu

Ostrzeżenia
- git configustawienia można zastąpić gitattributesustawieniami.
- crlf -> lfkonwersja następuje tylko podczas dodawania nowych plików, crlfnie ma to wpływu na pliki już istniejące w repozytorium.

Morał (dla Windows):
    - use core.autocrlf= truejeśli planujesz używać tego projektu również pod Uniksem (i nie chcesz konfigurować swojego edytora / IDE do używania zakończeń linii uniksowych),
    - use core.autocrlf= falsejeśli planujesz używać tego projektu tylko pod Windows ( lub skonfigurowałeś swój edytor / IDE do używania zakończeń linii uniksowych),
    - nigdy nie używaj core.autocrlf= inputchyba, że ​​masz ku temu dobry powód ( np. jeśli używasz narzędzi unixowych pod Windows lub jeśli masz problemy z plikami makefile),

PS Co wybrać, instalując git dla Windows?
Jeśli nie zamierzasz używać żadnego z projektów w systemie Unix, nie zgadzaj się z domyślną pierwszą opcją. Wybierz trzeci ( Checkout as-is, commit as-is ). Nie zobaczysz tej wiadomości. Zawsze.

PPS Moje osobiste preferencje to konfiguracja edytora / IDE do używania zakończeń w stylu uniksowym i ustawienie core.autocrlfna false.

Git ma trzy tryby traktowania zakończenia linii:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Możesz ustawić tryb, który ma być używany, dodając dodatkowy parametr truelub falsedo powyższej linii poleceń.

Jeśli core.autocrlfjest ustawiony na true, oznacza to, że za każdym razem, gdy dodasz plik do repozytorium git, który git uważa za plik tekstowy, zamieni wszystkie zakończenia linii CRLF na tylko LF, zanim zapisze go w zatwierdzeniu. Ilekroć git checkoutcoś zrobisz , wszystkie pliki tekstowe będą automatycznie konwertowane na końce linii LF na końce CRLF. Pozwala to na rozwój projektu na platformach, które używają różnych stylów zakończenia linii bez zatwierdzania, ponieważ każdy edytor zmienia styl zakończenia linii, ponieważ styl zakończenia linii jest zawsze konsekwentnie LF.

Efektem ubocznym tej wygodnej konwersji, i to właśnie jest to ostrzeżenie, które widzisz, jest to, że jeśli pierwotnie utworzony plik tekstowy miał końce 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. Ostrzeżenie jest w tym przypadku „dla twojej informacji”, ale w przypadku, gdy git niepoprawnie oceni plik binarny jako plik tekstowy, jest to ważne ostrzeżenie, ponieważ git może wtedy uszkodzić plik binarny.

Jeśli core.autocrlfustawiono wartość false, konwersja końca linii nie jest nigdy wykonywana, więc pliki tekstowe są sprawdzane w niezmienionej postaci. Zwykle działa to dobrze, o ile wszyscy programiści pracują w systemie Linux lub wszyscy w systemie Windows. Ale z mojego doświadczenia wciąż mam tendencję do otrzymywania plików tekstowych z mieszanymi zakończeniami linii, które powodują problemy.

Osobiście wolę pozostawić ustawienie WŁĄCZONE jako programista Windows.

Zobacz http://kernel.org/pub/software/scm/git/docs/git-config.html, aby uzyskać zaktualizowane informacje, które obejmują wartość „wejściową”.

Jeśli kod został już pobrany, pliki są już indeksowane. Po zmianie ustawień git powiedz, uruchamiając:

git config --global core.autocrlf input 

należy odświeżyć indeksy za pomocą

git rm --cached -r . 

i ponownie napisz indeks git za pomocą

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Uwaga: spowoduje to usunięcie lokalnych zmian, zastanów się nad ich zapisaniem, zanim to zrobisz.

git config core.autocrlf false

Zarówno unix2dos, jak i dos2unix są dostępne w systemie Windows z gitbash. Możesz użyć następującego polecenia, aby wykonać konwersję UNIX (LF) -> DOS (CRLF). Dlatego nie dostaniesz ostrzeżenia.

unix2dos filename

lub

dos2unix -D filename

Ale nie uruchamiaj tego polecenia na żadnym istniejącym pliku CRLF, wtedy co drugi wiersz będziesz otrzymywać puste znaki nowej linii.

dos2unix -D filenamenie będzie działać z każdym systemem operacyjnym. Sprawdź ten link pod kątem zgodności.

Jeśli z jakiegoś powodu musisz wymusić polecenie, użyj --force. Jeśli mówi nieważne następnie użyć -f.

Myślę @ Basiloungas za odpowiedź jest blisko, ale nieaktualne (przynajmniej na Macu).

Otwórz plik ~ / .gitconfig i ustaw wartość safecrlffalse

[core]
       autocrlf = input
       safecrlf = false

To * sprawi, że zignoruje znak końca linii najwyraźniej (w każdym razie pracował dla mnie).

Artykuł GitHub na temat zakończeń linii jest często wspominany podczas omawiania tego tematu.

Moje osobiste doświadczenia z używaniem często zalecanego core.autocrlfustawienia konfiguracji były bardzo zróżnicowane.

Używam systemu Windows z Cygwin, zajmując się projektami Windows i UNIX w różnym czasie. Nawet moje projekty Windows czasami używają bashskryptów powłoki, które wymagają zakończenia linii UNIX (LF).

Korzystając z zalecanego core.autocrlfustawienia GitHub dla systemu Windows, jeśli sprawdzę projekt UNIX (który działa doskonale na Cygwin - a może przyczyniam się do projektu, którego używam na serwerze Linux), pliki tekstowe są sprawdzane w systemie Windows (CRLF ) zakończenia linii, stwarzając problemy.

Zasadniczo w środowisku mieszanym, takim jak ja, ustawienie globalne core.autocrlfna dowolną z opcji nie działa dobrze w niektórych przypadkach. Ta opcja może być ustawiona w lokalnej konfiguracji git (repozytorium), ale nawet to nie byłoby wystarczające dla projektu zawierającego rzeczy związane zarówno z Windows, jak i UNIX (np. Mam projekt Windows z niektórymi bashskryptami narzędziowymi).

Najlepszym wyborem, jaki znalazłem, jest utworzenie plików .gitattributes dla repozytorium . Artykuł w GitHub wspomina o tym.
Przykład z tego artykułu:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

W jednym z repozytoriów mojego projektu:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

Jest nieco więcej rzeczy do skonfigurowania, ale zrób to raz na projekt, a każdy współpracownik w dowolnym systemie operacyjnym nie powinien mieć problemów z zakończeniami linii podczas pracy z tym projektem.

W vimie otwórz plik (np .:) :e YOURFILEENTER, a następnie

:set noendofline binary
:wq

Też miałem ten problem.

SVN nie wykonuje żadnej konwersji końca linii, więc pliki są zatwierdzane z nienaruszonymi zakończeniami linii CRLF. Jeśli następnie użyjesz git-svn, aby umieścić projekt w git, wówczas zakończenia CRLF pozostają w repozytorium git, co nie jest stanem, w którym git oczekuje się znaleźć - domyślnie jest to, że mają tylko zakończenia linii unix / linux (LF) zakwaterowany.

Gdy następnie wyewidencjonujesz pliki w systemie Windows, konwersja autocrlf pozostawia pliki nietknięte (ponieważ mają już prawidłowe zakończenia dla bieżącej platformy), jednak proces, który decyduje, czy istnieje różnica w stosunku do plików sprawdzanych, wykonuje odwrotną konwersję przed porównaniem, co powoduje porównanie tego, co uważa za LF w pobranym pliku z nieoczekiwanym CRLF w repozytorium.

O ile widzę, twoje wybory to:

1. Ponownie zaimportuj kod do nowego repozytorium git bez użycia git-svn, co oznacza, że ​​zakończenia linii są konwertowane w początkowym git commit --all
2. Ustaw autocrlf na false i zignoruj ​​fakt, że zakończenia linii nie są w preferowanym stylu gita
3. Sprawdź swoje pliki przy wyłączonym autocrlf, napraw wszystkie zakończenia linii, sprawdź wszystko z powrotem i włącz je ponownie.
4. Przepisz historię swojego repozytorium, aby oryginalne zatwierdzenie nie zawierało już CRLF, którego git się nie spodziewał. (Obowiązują zwykłe zastrzeżenia dotyczące przepisywania historii)

Przypis: jeśli wybierzesz opcję # 2, to z mojego doświadczenia wynika, że ​​niektóre narzędzia pomocnicze (rebase, łatka itp.) Nie radzą sobie z plikami CRLF i prędzej czy później skończysz z plikami z mieszanką CRLF i LF (niespójna linia zakończenia). Nie znam żadnego sposobu, aby uzyskać to, co najlepsze.

Usuwanie poniżej z pliku ~ / .gitattributes

* text=auto

zapobiegnie sprawdzeniu przez git zakończenia linii na pierwszym miejscu.

Powinien brzmieć:

ostrzeżenie: ( Jeśli zaznaczysz go / sklonujesz do innego folderu z obecnym plikiem core.autocrlftrue ,) LF zostanie zastąpiony przez CRLF

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

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

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Zrób to na osobnym zatwierdzeniu lub git może nadal widzieć całe pliki jako zmodyfikowane po dokonaniu jednej zmiany (w zależności od tego, czy zmieniłeś opcję autocrlf)

Ten naprawdę działa. Git będzie szanował zakończenia linii w projektach kończących linie mieszane i nie ostrzegał o nich.

Nie wiem dużo o git na Windowsie, ale ...

Wydaje mi się, że git konwertuje format zwracany na zgodny z uruchomioną platformą (Windows). CRLF jest domyślnym formatem zwrotu w systemie Windows, natomiast LF jest domyślnym formatem zwrotu dla większości innych systemów operacyjnych.

Możliwe, że format zwrotu zostanie odpowiednio dostosowany, gdy kod zostanie przeniesiony do innego systemu. Uważam również, że git jest wystarczająco inteligentny, aby zachowywać nienaruszone pliki binarne, zamiast próbować konwertować LF na CRLF, powiedzmy, w JPEG.

Podsumowując, prawdopodobnie nie musisz się zbytnio przejmować tą konwersją. Jeśli jednak zarchiwizujesz swój projekt jako archiwum, inni koderzy prawdopodobnie doceniliby raczej terminatory linii LF niż CRLF. W zależności od tego, jak bardzo ci zależy (i w zależności od tego, czy nie korzystasz z Notatnika), możesz ustawić git, aby używał zwrotów LF, jeśli możesz :)

Dodatek: CR to kod ASCII 13, LF to kod ASCII 10. Zatem CRLF ma dwa bajty, a LF jeden.

Upewnij się, że masz zainstalowany najnowszy git.
Zrobiłem jak wyżej git config core.autocrlf false, gdy użyłem git (wersja 2.7.1), ale to nie działało.
Następnie działa teraz, gdy zaktualizujesz git (z 2.7.1 do 2.20.1).

1. Otwórz plik w Notepad ++.
2. Przejdź do edycji / konwersji EOL.
3. Kliknij, aby przejść do formatu Windows.
4. Zapisz plik.

Pytanie OP dotyczy systemu Windows i nie mogłem korzystać z innych bez wchodzenia do katalogu lub nawet uruchamiania pliku w Notepad ++, ponieważ administrator nie działał. Musiałem więc pójść tą drogą:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

Wiele edytorów tekstu pozwala na zmianę LF, patrz instrukcje Atom poniżej. Prosty i wyraźny.

Kliknij CRLFw prawym dolnym rogu:

Wybierz LFw menu u góry:

W wierszu poleceń powłoki GNU / Linux polecenia dos2unix i unix2dos pozwalają na łatwą konwersję / formatowanie plików pochodzących z MS Windows

CRLF może powodować problemy podczas korzystania z „kodu” w dwóch różnych systemach operacyjnych (Linux i Windows). Mój skrypt Pythona został napisany w kontenerze dokera Linuksa, a następnie wypchnięty za pomocą git-bash systemu Windows. Ostrzegło mnie, że LF zostanie zastąpiony przez CRLF. Nie zastanawiałem się nad tym, ale kiedy później zacząłem pisać scenariusz, powiedział /usr/bin/env: 'python\r': No such file or directory. Teraz jest \rdla ciebie rozgałęzienie. Windows używa „CR” - znak powrotu karetki - na górze „\ n” jako nowego znaku linii - \n\r. To może być coś do rozważenia.

Większość narzędzi w systemie Windows akceptuje tylko pliki LF w plikach tekstowych. Na przykład możesz kontrolować zachowanie programu Visual Studio w pliku o nazwie „.editorconfig” za pomocą następującej przykładowej treści (części):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Tylko oryginalny Notatnik Windows nie działa z LF, ale dostępne są bardziej odpowiednie proste narzędzia edytora!

Dlatego powinieneś używać LF również w plikach tekstowych w systemie Windows. To jest moja wiadomość, szczególnie polecana! Nie ma powodu, aby używać CRLF w systemie Windows!

(Ta sama dyskusja używa \ in ścieżek włączania w C / ++, to bzdura, użyj #include <pathTo / myheader.h> z ukośnikiem !, Jest to standard C / ++ i wszystkie kompilatory Microsoft obsługują go).

Dlatego właściwym ustawieniem dla git jest

git config core.autocrlf false

Moja wiadomość: Zapomnij o tak starych programach myślących, jak dos2unix i unix2dos. Wyjaśnij w swoim zespole, że LF można używać w systemie Windows.