Jak konwersje kończące linię działają z git core.autocrlf między różnymi systemami operacyjnymi

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:

1. Jakie powinny być znaki zapytania?
2. 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ń.

Najlepsze wyjaśnienie tego, jak core.autocrlfdziała, można znaleźć na stronie man gitattributes w textsekcji atrybutów.

Oto jak core.autocrlfwydaje się działać obecnie (a przynajmniej od wersji 1.7.2 z tego, co wiem):

• core.autocrlf = true
  1. Pliki tekstowe wyrejestrowane z repozytorium, które zawierają tylko LFznaki, są znormalizowane CRLFw twoim drzewie roboczym; pliki zawierające CRLFw repozytorium nie zostaną dotknięte
  2. Pliki tekstowe, które mają tylko LFznaki w repozytorium, są znormalizowane od CRLFdo LFpo przywróceniu do repozytorium. Pliki zawarte CRLFw repozytorium zostaną zatwierdzone bez zmian.
• core.autocrlf = input
  1. Pliki tekstowe wyewidencjonowane z repozytorium zachowają oryginalne znaki EOL w twoim drzewie roboczym.
  2. Pliki tekstowe w twoim drzewie roboczym ze CRLFznakami są znormalizowane LFpo przywróceniu do repozytorium.
• core.autocrlf = false
  1. core.eol dyktuje znaki EOL w plikach tekstowych twojego drzewa roboczego.
  2. core.eol = nativedomyślnie oznacza to, że Windows EOL są, CRLFa * nix EOL są LFw działających drzewach.
  3. gitattributesUstawienia repozytorium określają normalizację znaków EOL dla zatwierdzeń do repozytorium (domyślnie jest to normalizacja LFznaków).

Dopiero niedawno badałem ten problem i uważam, że sytuacja jest bardzo skomplikowana. core.eolUstawienie zdecydowanie pomogły wyjaśnienia, w jaki sposób znaki końca linii są obsługiwane przez git.

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:

1. Repozytorium może mieć różne pliki z różnymi EOL
2. Niektóre pliki w repo mogą mieć mieszane EOL, np kombinacji CRLFi LFw 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:

                 | Wynikowa konwersja, gdy | Wynikowa konwersja kiedy
                 | zatwierdzanie plików z różnymi | sprawdzanie z repo -
                 | EOL na repozytorium i | z mieszanymi plikami i
                 | Wartość core.autocrlf: | Wartość core.autocrlf:           
-------------------------------------------------- ------------------------------
Plik | prawda | wejście | fałsz | prawda | wejście | fałszywe
-------------------------------------------------- ------------------------------
Windows-CRLF | CRLF -> LF | CRLF -> LF | jak jest | jak jest | jak jest | jak jest
Unix -LF | jak jest | jak jest | jak jest | LF -> CRLF | jak jest | jak jest
Mac -CR | jak jest | jak jest | jak jest | jak jest | jak jest | jak jest
Mieszane CRLF + LF | jak jest | jak jest | jak jest | jak jest | jak jest | jak jest
Mieszane-CRLF + LF + CR | jak jest | jak jest | jak jest | jak jest | jak jest | jak jest

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:

1. core.autocrlfjest true i
2. plik w repozytorium ma LFEOL.

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+ LFnormalizuje się.

Zauważ też, że tylko „stare” EOL dla komputerów Mac CRnigdy nie są konwertowane.
Oznacza to, że jeśli źle napisany skrypt konwersji EOL spróbuje przekonwertować plik o mieszanym zakończeniu za pomocą CRLFs + LFs, po prostu konwertując LFs na CRLFs, pozostawi plik w trybie mieszanym z „samotnymi” CRs, gdziekolwiek CRLFkonwertowano a CRCRLF.
Git niczego nie skonwertuje, nawet w truetrybie, 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 inputlub false, uruchomienie właściwej normalizacji i ponowne zatwierdzenie zmienionych plików (jeśli takie istnieją). W systemie Windows prawdopodobnie wznowiono pracę z core.autocrlf true.

Wszystko się zmieni na froncie „konwersji eol” wraz z nadchodzącym Gitem 1.7.2 :

Nowe ustawienie konfiguracji core.eoljest dodawane / rozwijane :

Jest to zamiennik core.eolaktualnie zatwierdzonego zatwierdzenia „Dodaj” „zmienną konfiguracyjną” pu(ostatnia z mojej serii).
Zamiast sugerować, że „ core.autocrlf=true” jest zamiennikiem „ * text=auto”, wyjaśnia to fakt, że autocrlfjest to tylko dla użytkowników, którzy chcą pracować z CRLF w swoim katalogu roboczym w repozytorium, które nie ma normalizacji plików tekstowych .
Po włączeniu „core.eol” jest ignorowany.

Wprowadź nową zmienną konfiguracyjną „ core.eol”, która pozwala użytkownikowi ustawić, które zakończenia linii mają być używane dla plików znormalizowanych na końcu linii w katalogu roboczym.
Domyślnie jest to „ native”, co oznacza CRLF w systemie Windows i LF wszędzie indziej. Pamiętaj, że „ core.autocrlf” zastępuje core.eol.
To znaczy że:

[core]
  autocrlf = true

umieszcza CRLF w katalogu roboczym, nawet jeśli core.eoljest ustawiony na „ lf”.

core.eol:

Ustawia typ zakończenia linii do użycia w katalogu roboczym dla plików, które mają textustawioną właściwość.
Alternatywami są „lf”, „crlf” i „native”, które korzystają z zakończenia linii macierzystej platformy.
Wartość domyślna to native.

Rozważane są inne zmiany :

Do 1,8, chciałbym rozważyć core.autocrlfwystarczy włączyć normalizacji i pozostawić linię końcową decyzję katalog roboczy do core.eol, ale że będzie złamać ustawień ludzi.

git 2.8 (marzec 2016) poprawia sposób, w jaki core.autocrlfwpł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.)}

convert.c: refaktor crlf_action

Refaktoryzuj ustalenie i użycie crlf_action.
Dzisiaj, gdy crlfw pliku nie crlf_actionma ustawionego atrybutu „ ”, ustawia się na CRLF_GUESS. CRLF_UNDEFINEDZamiast tego użyj i wyszukaj „ text” lub „ eol” jak poprzednio.

Zamień stare CRLF_GUESSużycie:

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Wyjaśnij, co jest, definiując:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

Jak dodaje torek w komentarzach :

wszystkie te tłumaczenia (dowolna konwersja eol=lub autocrlfustawienia EOL oraz cleanfiltry „ ”) są uruchamiane, gdy pliki przenoszą się z drzewa roboczego do indeksu , tj. git addraczej w git commitczasie niż w czasie.
(Należy pamiętać, że git commit -aalbo --onlyczy --includezrobić pliki dodane do indeksu w tym czasie, choć.)

Aby uzyskać więcej informacji na ten temat, zobacz „ Jaka jest różnica między autocrlf a eol ”.

core.autocrlfwartość nie zależy od typu systemu operacyjnego, ale wartością domyślną systemu Windows jest truei dla systemu Linux - input. Zbadałem 3 możliwe wartości przypadków zatwierdzenia i kasy i oto wynikowa tabela:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Oto moje dotychczasowe zrozumienie, na wypadek, gdyby komuś to pomogło.

core.autocrlf=true i core.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.

Nie, odpowiedź @jmlane jest nieprawidłowa.

Dla Checkin (git add, git commit):

1. jeśli textwłaściwość jest Set, Set value to 'auto', konwersja nastąpi, nawet jeśli plik został zatwierdzony za pomocą „CRLF”
2. jeśli textwłaściwość jest Unset: nic się nie dzieje, enenCheckout
3. jeśli textwłaściwość jest Unspecified, konwersja zależy odcore.autocrlf
   1. jeśli autocrlf = input or autocrlf = truekonwersja nastąpi tylko wtedy, gdy plik w repozytorium to „LF”, jeśli był to „CRLF”, nic się nie stanie.
   2. jeśli autocrlf = falsenic się nie stanie

Dla Checkout:

1. jeśli textwłaściwość jest Unset: nic się nie dzieje.
2. jeżeli textnieruchomość jest Set, Set value to 'auto: to zależy core.autocrlf, core.eol.
   1. core.autocrlf = input: nic się nie dzieje
   2. core.autocrlf = true: konwersja ma miejsce tylko wtedy, gdy plik w repozytorium to „LF”, „LF” -> „CRLF”
   3. core.autocrlf = false: konwersja następuje tylko wtedy, gdy plik w repozytorium to „LF”, „LF” -> core.eol
3. jeśli textwłaściwość jest Unspecified, to zależy od core.autocrlf.
   1. taki sam jak 2.1
   2. taki sam jak 2.2
   3. Brak, nic się nie dzieje, core.eol nie działa, gdy textwłaściwość jestUnspecified

Domyślne zachowanie

Domyślnym zachowaniem jest textwłaściwość Unspecifiedi core.autocrlf = false:

1. do odprawy nic się nie dzieje
2. do kasy nic się nie dzieje

Wnioski

1. jeśli textwłaściwość jest ustawiona, zachowanie podczas sprawdzania zależy od samego siebie, a nie od autocrlf
2. autocrlf lub core.eol służy do obsługi transakcji, a autocrlf> core.eol

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.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF