Przeczytałem wiele różnych pytań i odpowiedzi na temat przepełnienia stosu, a także dokumentację git na temat działania ustawienia core.autocrlf .
Oto moje zrozumienie z tego, co przeczytałem:
Klienci Unix i Mac OSX (wcześniejsi niż OSX używają CR) używają zakończeń linii LF.
Klienci Windows używają zakończeń linii CRLF.
Gdy core.autocrlf jest ustawiony na true na kliencie, repozytorium git zawsze przechowuje pliki w formacie końca linii LF, a zakończenia linii w plikach na kliencie są konwertowane tam i z powrotem przy kasie / zatwierdzeniu dla klientów (tj. Windows), którzy używają innych niż -LF zakończenia linii, bez względu na format plików zakończenia linii na kliencie (nie zgadza się to z definicją Tima Clema - patrz aktualizacja poniżej).
Oto macierz, która próbuje udokumentować to samo dla ustawień „wejściowych” i „fałszywych” core.autocrlf ze znakami zapytania, w których nie jestem pewien zachowania konwersji kończącego linię.
Moje pytania to:
- Jakie powinny być znaki zapytania?
- Czy ta matryca jest poprawna dla „znaków niekwestionowanych”?
Zaktualizuję znaki zapytania w odpowiedziach, ponieważ wydaje się, że osiągnięto konsensus.
wartość core.autocrlf true wejście false -------------------------------------------------- -------- popełnić | nawrócić? ? nowy | na LF (konwersja na LF?) (bez konwersji?) popełnić | Konwertuj na ? Nie istniejący | Konwersja LF (konwersja na LF?) kasa | Konwertuj na ? Nie istniejący | Konwersja CRLF (bez konwersji?)
Tak naprawdę nie szukam opinii na temat zalet i wad różnych ustawień. Po prostu szukam danych, które wyjaśniają, jak można oczekiwać, że git będzie działał z każdym z trzech ustawień.
-
Aktualizacja 17.04.2012 : Po przeczytaniu artykułu Tima Clema połączonego przez JJD w komentarzach zmodyfikowałem niektóre wartości w „nieznanych” wartościach w powyższej tabeli, a także zmieniłem „kasy” istniejące | true do konwersji na CRLF zamiast konwertować na klienta ". Oto podane przez niego definicje, które są bardziej jasne niż cokolwiek, co widziałem gdzie indziej:
core.autocrlf = false
Jest to ustawienie domyślne, ale większość ludzi zachęca się do natychmiastowej zmiany. W wyniku użycia fałszu Git nigdy nie zadziera z zakończeniami linii w twoim pliku. Możesz rejestrować pliki za pomocą LF, CRLF lub CR lub jakiejś losowej mieszanki tych trzech, a Git nie dba o to. Może to utrudniać odczytanie różnic i utrudnia scalanie. Większość ludzi pracujących w świecie Unix / Linux używa tej wartości, ponieważ nie mają problemów z CRLF i nie potrzebują Git do wykonywania dodatkowej pracy za każdym razem, gdy pliki są zapisywane w bazie danych obiektów lub zapisywane w katalogu roboczym.
core.autocrlf = true
Oznacza to, że Git przetworzy wszystkie pliki tekstowe i dopilnuje, aby CRLF został zastąpiony przez LF podczas zapisywania tego pliku w bazie danych obiektów i przekształcił wszystkie LF z powrotem w CRLF podczas zapisywania do katalogu roboczego. Jest to zalecane ustawienie w systemie Windows, ponieważ zapewnia, że repozytorium może być używane na innych platformach, zachowując jednocześnie CRLF w katalogu roboczym.
core.autocrlf = dane wejściowe
Oznacza to, że Git przetworzy wszystkie pliki tekstowe i dopilnuje, aby CRLF został zastąpiony LF podczas zapisywania tego pliku w bazie danych obiektów. Nie zrobi to jednak odwrotnie. Kiedy odczytasz pliki z bazy danych obiektów i zapiszesz je w katalogu roboczym, nadal będą miały wartości LF do oznaczenia końca linii. To ustawienie jest zwykle używane w systemach Unix / Linux / OS X, aby zapobiec zapisywaniu CRLF w repozytorium. Pomysł polega na tym, że jeśli wkleisz kod z przeglądarki internetowej i przypadkowo umieścisz CRLF w jednym ze swoich plików, Git upewni się, że zostały one zastąpione LF podczas pisania do bazy danych obiektów.
Artykuł Tima jest doskonały, jedyne, co mogę o tym myśleć, to to, że zakłada, że repozytorium ma format LF, co niekoniecznie jest prawdą, szczególnie w przypadku projektów wyłącznie dla systemu Windows.
Porównanie artykułu Tima z najwyżej ocenioną dotychczas odpowiedzią autorstwa jmlane pokazuje doskonałą zgodność co do prawdziwych i wejściowych ustawień oraz brak zgody co do fałszywych ustawień.
źródło
autocrlf
się fałszu wydaje się o wiele łatwiejsze;) stackoverflow.com/questions/2333424/…Odpowiedzi:
Najlepsze wyjaśnienie tego, jak
core.autocrlf
działa, można znaleźć na stronie man gitattributes wtext
sekcji atrybutów.Oto jak
core.autocrlf
wydaje się działać obecnie (a przynajmniej od wersji 1.7.2 z tego, co wiem):core.autocrlf = true
LF
znaki, są znormalizowaneCRLF
w twoim drzewie roboczym; pliki zawierająceCRLF
w repozytorium nie zostaną dotknięteLF
znaki w repozytorium, są znormalizowane odCRLF
doLF
po przywróceniu do repozytorium. Pliki zawarteCRLF
w repozytorium zostaną zatwierdzone bez zmian.core.autocrlf = input
CRLF
znakami są znormalizowaneLF
po przywróceniu do repozytorium.core.autocrlf = false
core.eol
dyktuje znaki EOL w plikach tekstowych twojego drzewa roboczego.core.eol = native
domyślnie oznacza to, że Windows EOL są,CRLF
a * nix EOL sąLF
w działających drzewach.gitattributes
Ustawienia repozytorium określają normalizację znaków EOL dla zatwierdzeń do repozytorium (domyślnie jest to normalizacjaLF
znaków).Dopiero niedawno badałem ten problem i uważam, że sytuacja jest bardzo skomplikowana.
core.eol
Ustawienie zdecydowanie pomogły wyjaśnienia, w jaki sposób znaki końca linii są obsługiwane przez git.źródło
core.autocrlf = false
jeśli nie mamgitattributes
pliku, czy to oznacza, że nie będzie normalizacji? Czy oznacza to, że użyje domyślnej normalizacji?.gitattributes
plik nie powinien mieć pierwszeństwa przedcore.autocrlf
ustawieniem?Kwestia EOL w projektach na różnych platformach od dawna czyni moje życie nieszczęśliwym. Problemy wynikają zazwyczaj, gdy istnieją już pliki z różnych, mieszanych EOLs już w repo. To znaczy że:
CRLF
iLF
w tym samym pliku.To, jak to się dzieje, nie jest tutaj problemem, ale się zdarza.
Przeprowadziłem kilka testów konwersji w systemie Windows dla różnych trybów i ich kombinacji.
Oto, co dostałem, w nieco zmodyfikowanej tabeli:
Jak widać, istnieją 2 przypadki, w których konwersja odbywa się przy zatwierdzeniu (3 lewe kolumny). W pozostałych przypadkach pliki są zatwierdzane w stanie, w jakim się znajdują.
Przy kasie (3 kolumny po prawej) występuje tylko 1 przypadek, w którym konwersja następuje:
core.autocrlf
jesttrue
iLF
EOL.Najbardziej zaskakujące jest dla mnie i podejrzewam, że przyczyną wielu problemów z EOL jest brak konfiguracji, w której mieszane EOL jak
CRLF
+LF
normalizuje się.Zauważ też, że tylko „stare” EOL dla komputerów Mac
CR
nigdy nie są konwertowane.Oznacza to, że jeśli źle napisany skrypt konwersji EOL spróbuje przekonwertować plik o mieszanym zakończeniu za pomocą
CRLF
s +LF
s, po prostu konwertującLF
s naCRLF
s, pozostawi plik w trybie mieszanym z „samotnymi”CR
s, gdziekolwiekCRLF
konwertowano aCRCRLF
.Git niczego nie skonwertuje, nawet w
true
trybie, i spustoszenie EOL trwa. Zdarzyło mi się to i bardzo źle popsułem moje pliki, ponieważ niektóre edytory i kompilatory (np. VS2010) nie lubią Mac EOL-ów.Wydaje mi się, że jedynym sposobem, aby naprawdę poradzić sobie z tymi problemami, jest od czasu do czasu normalizacja całego repo poprzez sprawdzenie wszystkich plików w trybie
input
lubfalse
, uruchomienie właściwej normalizacji i ponowne zatwierdzenie zmienionych plików (jeśli takie istnieją). W systemie Windows prawdopodobnie wznowiono pracę zcore.autocrlf true
.źródło
core.autocrlf true
. Osobiście uważam, żeinput
należy tego zawsze używać.Wszystko się zmieni na froncie „konwersji eol” wraz z nadchodzącym Gitem 1.7.2 :
Nowe ustawienie konfiguracji
core.eol
jest dodawane / rozwijane :Rozważane są inne zmiany :
git 2.8 (marzec 2016) poprawia sposób, w jaki
core.autocrlf
wpływa na eol:Zobacz popełnić 817a0c7 (23 lut 2016), popełnić 6e336a5 , popełnić df747b8 , popełnić df747b8 (10 lut 2016), popełnić df747b8 , popełnić df747b8 (10 lut 2016) i popełnić 4b4024f , popełnić bb211b4 , popełnić 92cce13 , popełnić 320d39c , popełnić 4b4024f , commit bb211b4 , commit 92cce13 , commit 320d39c (05 lut 2016) autor: Torsten Bögershausen (
tboegi
) .(Scalony przez Junio C Hamano -
gitster
- in commit c6b94eb, 26 lutego 2016 r.)Jak dodaje torek w komentarzach :
Aby uzyskać więcej informacji na ten temat, zobacz „ Jaka jest różnica między autocrlf a eol ”.
źródło
core.eol
chodzi o „automatyczną modyfikację” tylko tego, co wyraźnie deklarujesz w.gitattributes
pliku. Różni się to od tego,core.autocrlf
który dotyczy dowolnego pliku w repozytorium. Jest to proces deklaratywny.git add
Raczej wgit commit
czasie niż w czasie. (Należy pamiętać, żegit commit -a
albo--only
czy--include
zrobić pliki dodane do indeksu w tym czasie, choć). Na co warto, ty i ja i Linus Torvalds wszystkie nienawidzę idei VCS kiedykolwiek modyfikacji, co jest zaangażowana. Ale są wszyscy użytkownicy systemu Windows ... :-)core.autocrlf
wartość nie zależy od typu systemu operacyjnego, ale wartością domyślną systemu Windows jesttrue
i dla systemu Linux -input
. Zbadałem 3 możliwe wartości przypadków zatwierdzenia i kasy i oto wynikowa tabela:źródło
CR
tylko jedno urządzenie nigdy nie są dotykane.false
nigdy nie dotyka końcówek linii.true
zawsze zatwierdza jakoLF
i sprawdza jakoCRLF
. Iinput
zawsze zatwierdza sięLF
i sprawdza jak jest.Oto moje dotychczasowe zrozumienie, na wypadek, gdyby komuś to pomogło.
core.autocrlf=true
icore.safecrlf = true
Masz repozytorium, w którym wszystkie zakończenia linii są takie same , ale pracujesz na różnych platformach. Git upewni się, że zakończenia linii są konwertowane na domyślne dla twojej platformy. Dlaczego to ma znaczenie? Załóżmy, że tworzysz nowy plik. Edytor tekstu na twojej platformie użyje domyślnych zakończeń linii. Kiedy go rejestrujesz, jeśli nie masz ustawionego core.autocrlf na true, wprowadziłeś niespójność kończącą linię dla kogoś na platformie, która domyślnie ma inne zakończenie linii. Zawsze ustawiam też safecrlf, ponieważ chciałbym wiedzieć, że operacja crlf jest odwracalna. Przy tych dwóch ustawieniach git modyfikuje pliki, ale sprawdza, czy modyfikacje są odwracalne .
core.autocrlf=false
Masz repozytorium, w którym już sprawdzono mieszane zakończenia linii, a naprawienie nieprawidłowych zakończeń linii może spowodować uszkodzenie innych rzeczy. W tym przypadku najlepiej nie mówić gitowi, by zamieniał zakończenia linii, ponieważ wtedy zaostrzy to problem, który został rozwiązany - dzięki czemu różnice będą łatwiejsze do odczytania, a scalenia mniej bolesne. Przy tym ustawieniu git nie modyfikuje plików .
core.autocrlf=input
Nie używam tego, ponieważ ma to na celu pokrycie przypadku użycia, w którym utworzono plik z zakończeniami linii CRLF na platformie, która domyślnie ma zakończenia linii LF. Wolę zamiast tego, aby mój edytor tekstowy zawsze zapisywał nowe pliki z domyślnymi zakończeniami linii platformy.
źródło
Nie, odpowiedź @jmlane jest nieprawidłowa.
Dla
Checkin (git add, git commit)
:text
właściwość jestSet, Set value to 'auto'
, konwersja nastąpi, nawet jeśli plik został zatwierdzony za pomocą „CRLF”text
właściwość jestUnset
: nic się nie dzieje, enenCheckout
text
właściwość jestUnspecified
, konwersja zależy odcore.autocrlf
autocrlf = input or autocrlf = true
konwersja nastąpi tylko wtedy, gdy plik w repozytorium to „LF”, jeśli był to „CRLF”, nic się nie stanie.autocrlf = false
nic się nie stanieDla
Checkout
:text
właściwość jestUnset
: nic się nie dzieje.text
nieruchomość jestSet, Set value to 'auto
: to zależycore.autocrlf
,core.eol
.core.eol
text
właściwość jestUnspecified
, to zależy odcore.autocrlf
.2.1
2.2
text
właściwość jestUnspecified
Domyślne zachowanie
Domyślnym zachowaniem jest
text
właściwośćUnspecified
icore.autocrlf = false
:Wnioski
text
właściwość jest ustawiona, zachowanie podczas sprawdzania zależy od samego siebie, a nie od autocrlfźródło
Zrobiłem kilka testów zarówno na systemie Linux, jak i Windows. Używam pliku testowego zawierającego linie kończące się na LF, a także linie kończące się na CRLF.
Plik zostaje zatwierdzony, usunięty, a następnie wyrejestrowany. Wartość core.autocrlf jest ustawiana przed zatwierdzeniem, a także przed pobraniem. Wynik jest poniżej.
źródło