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.
Odpowiedzi:
Te komunikaty są spowodowane nieprawidłową wartością domyślną
core.autocrlf
w systemie Windows.Koncepcja
autocrlf
polega 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
autocrlf
działa :Tutaj
crlf
= marker końca linii w stylu win = = styllf
uniksowy (i Mac OSX).(
cr
nie wpływa na pre-osx dla żadnej z trzech powyższych opcji)Kiedy pojawia się to ostrzeżenie (w systemie Windows)
-
autocrlf
=true
jeśli masz styl uniksowylf
w jednym ze swoich plików (= RZADKO),-
autocrlf
=input
jeśli masz styl wygrywającycrlf
w 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żywajinput
pod oknami.Jeszcze inny sposób pokazania, jak
autocrlf
działagdzie x to CRLF (styl Windows) lub LF (styl unix), a strzałki oznaczają
Jak naprawić
Wartość domyślna dla
core.autocrlf
jest 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/config
lub -$HOME/.config/git/config
i„lokalny” (na repo) gitconfig
.git/config
w działającym katalogu.Napisz więc
git config core.autocrlf
działający katalog, aby sprawdzić aktualnie używaną wartość i- dodaj
autocrlf=false
do 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 projektuOstrzeżenia
-
git config
ustawienia można zastąpićgitattributes
ustawieniami.-
crlf -> lf
konwersja następuje tylko podczas dodawania nowych plików,crlf
nie ma to wpływu na pliki już istniejące w repozytorium.Morał (dla Windows):
- use
core.autocrlf
=true
jeś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
=false
jeś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
=input
chyba, ż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.autocrlf
nafalse
.źródło
core.autocrlf
wprowadzania? Z tego, co zebrałem z twojej odpowiedzi, ustawienie go na dane wejściowe zapewnia, że repozytorium i katalog roboczy zawsze mają zakończenia linii w stylu uniksowym. Dlaczego nigdy nie chcesz tego w systemie Windows?Git ma trzy tryby traktowania zakończenia linii:
Możesz ustawić tryb, który ma być używany, dodając dodatkowy parametr
true
lubfalse
do powyższej linii poleceń.Jeśli
core.autocrlf
jest 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 checkout
coś 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.autocrlf
ustawiono 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ą”.
źródło
core.eol
ustawień, być może w połączeniu z.gitattributes
konfiguracją. Próbowałem odkryć różnice i nakładanie się poprzez eksperymenty i jest to bardzo mylące.Jeśli kod został już pobrany, pliki są już indeksowane. Po zmianie ustawień git powiedz, uruchamiając:
należy odświeżyć indeksy za pomocą
i ponownie napisz indeks git za pomocą
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.
źródło
git rm --cached -r .
? Dlaczegogit reset --hard
nie wystarczy?git rm --cached -r .
Jeśli zrobisz togit reset --hard
po zmianiecore.autocrlf
ustawienia, nie spowoduje to ponownej konwersji zakończeń linii. Musisz wyczyścić indeks git.źródło
autcrlf
powoduje,false
że problem jest opisywany każdemu użytkownikowi projektu.git config --global core.autocrlf false
zamiast tego.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.
lub
Ale nie uruchamiaj tego polecenia na żadnym istniejącym pliku CRLF, wtedy co drugi wiersz będziesz otrzymywać puste znaki nowej linii.
dos2unix -D filename
nie 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
.źródło
dos2unix -D
konwertuje zakończenia linii systemu Windows na zakończenia linii systemu Linux. Czy to nie to samo, co konwersja DOS (CRLF) -> UNIX (LF). Jednakdos2unix -h
stany,-D
które wykonają konwersję UNIX (LF) -> DOS (CRLF). dos2unix Więcej informacji: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unixMyślę @ Basiloungas za odpowiedź jest blisko, ale nieaktualne (przynajmniej na Macu).
Otwórz plik ~ / .gitconfig i ustaw wartość
safecrlf
falseTo * sprawi, że zignoruje znak końca linii najwyraźniej (w każdym razie pracował dla mnie).
źródło
safecrlf
(z „f”)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.autocrlf
ustawienia 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ą
bash
skryptów powłoki, które wymagają zakończenia linii UNIX (LF).Korzystając z zalecanego
core.autocrlf
ustawienia 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.autocrlf
na 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órymibash
skryptami 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:
W jednym z repozytoriów mojego projektu:
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.
źródło
text=false eol=false
działało to trochę podobniebinary
. Czy to brzmi dobrze? Przydatne może być wskazanie „Wiem, że to pliki tekstowe, ale nie chcę, aby były znormalizowane”W vimie otwórz plik (np .:)
:e YOURFILE
ENTER, a następnieźródło
vim
pozostawiłaby nietknięte zakończenie linii.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:
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.
źródło
rebase
nie ma problemu z CRLF. Jedyny znany mi problem to to, że standardowe narzędzie do scalania git wstawi znaczniki konfliktu („<<<<<<”, „>>>>>>” itd.) Tylko w LF, więc plik ze znacznikami konfliktu mają mieszane zakończenia linii. Jednak po usunięciu znaczników wszystko jest w porządku.Usuwanie poniżej z pliku ~ / .gitattributes
* text=auto
zapobiegnie sprawdzeniu przez git zakończenia linii na pierwszym miejscu.
źródło
false
, jeśli ten nie zostanie usunięty, ustawienie autocrlf na false nie pomoże wiele, więc ten pomógł mi (ale sam nie wystarcza).text=
w.gitattributes
ogóle wspomina o ustawieniu (które, jeśli jest obecne, BĘDZIE blokować). Pozostałe odpowiedzi są niekompletne. Ja jechałem orzechy postać stara się, dlaczego moje pliki w dalszym ciągu pojawiają się jako „zmodyfikowany” bez względu na to, ile razy ja zmieniłemautocrlf
isafecrlf
ustawienia & wyrejestrowany i wyczyszczone cache git i twardy reset.Powinien brzmieć:
To zdjęcie powinno wyjaśniać, co to znaczy.
źródło
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/
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.
źródło
*.sh -crlf
cały czas ...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.
źródło
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).
źródło
źródło
git config --global core.autocrlf false
aby uniemożliwić Gitowi ustawianie zakończenia liniiUnix
na zatwierdzenie. Kontynuuj,git config core.autocrlf
aby sprawdzić, czy rzeczywiście jest ustawiony na false.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ą:
źródło
Wiele edytorów tekstu pozwala na zmianę
LF
, patrz instrukcje Atom poniżej. Prosty i wyraźny.Kliknij
CRLF
w prawym dolnym rogu:Wybierz
LF
w menu u góry:źródło
W wierszu poleceń powłoki GNU / Linux polecenia dos2unix i unix2dos pozwalają na łatwą konwersję / formatowanie plików pochodzących z MS Windows
źródło
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\r
dla 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.źródło
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):
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
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.
źródło