Dlaczego powinienem używać core.autocrlf = true w Git?

Mam repozytorium Git, do którego można uzyskać dostęp zarówno z systemu Windows, jak i OS X, i wiem, że zawiera już niektóre pliki z zakończeniami linii CRLF. O ile mi wiadomo, istnieją dwa sposoby radzenia sobie z tym:

1. Ustaw core.autocrlfsię falsewszędzie,

2. Postępuj zgodnie z instrukcjami tutaj (powtórzonymi na stronach pomocy GitHub), aby przekonwertować repozytorium tak, aby zawierało tylko zakończenia linii LF, a następnie ustawić core.autocrlfje truew systemie Windows i inputOS X. Problem z tym polega na tym, że jeśli mam jakieś pliki binarne w repozytorium że:

   1. nie są poprawnie oznaczone jako binarne w gitattributes, i
   2. zawiera zarówno CRLF, jak i LF,

   będą skorumpowani. Możliwe, że moje repozytorium zawiera takie pliki.

Dlaczego więc nie miałbym po prostu wyłączyć końcowej konwersji Gita? W sieci jest wiele niejasnych ostrzeżeń o core.autocrlfwyłączeniu powodującym problemy, ale bardzo niewiele konkretnych ; jedyne, co do tej pory znalazłem, to to, że kdiff3 nie może obsłużyć zakończeń CRLF (nie jest to dla mnie problemem) i że niektóre edytory tekstu mają problemy z zakończeniem linii (również dla mnie nie stanowi problemu).

Repozytorium jest wewnętrzne dla mojej firmy, więc nie muszę się martwić udostępnianiem go osobom o różnych ustawieniach autocrlf lub wymaganiach dotyczących zakończenia linii.

Czy są jakieś inne problemy z pozostawieniem zakończenia linii takim, jakiego nie jestem świadomy?

Jedyne konkretne powody, aby ustawić autocrlfna trueto:

• unikaj git statuswyświetlania wszystkich plików, modifiedponieważ następuje automatyczna konwersja EOL podczas klonowania repozytorium EOL Git opartego na Uniksie na Windowsie ( na przykład patrz problem 83 )
• a narzędzia do kodowania w jakiś sposób zależą od natywnego stylu EOL obecnego w pliku:
  • na przykład generator kodu zakodowany na stałe w celu wykrycia natywnego EOL
  • inne zewnętrzne partie (poza repozytorium) z wyrażeniem regularnym lub kodem ustawionym na wykrywanie natywnego EOL
  • Wierzę, że niektóre wtyczki Eclipse mogą generować pliki z CRLF niezależnie od platformy, co może być problemem.
  • Kodujesz za pomocą Notepad.exe ( chyba że używasz systemu Windows 10 2018.09+, w którym Notatnik uznaje wykryty znak EOL ).

Chyba widać specjalnej obróbce, która musi radzić sobie z natywnym EOL, jesteś lepiej pozostawiając autocrlfdofalse ( git config --global core.autocrlf false).

Zauważ, że ta konfiguracja byłaby lokalna (ponieważ config nie jest przekazywany z repo do repo)

Jeśli chcesz mieć tę samą konfigurację dla wszystkich użytkowników klonujących to repozytorium, sprawdź „ Jaka jest najlepsza CRLFstrategia obsługi z git? ”, Używając textatrybutu w .gitattributespliku .

Przykład:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Uwaga: począwszy od gita 2.8 (marzec 2016), znaczniki scalające nie będą już wprowadzać mieszanego zakończenia linii (LF) w pliku CRLF.
Zobacz „ Spraw, aby Git używał CRLF na liniach scalających„ HEAD ”<<<<<<< ”

Jestem programistą .NET i od lat korzystam z Git i Visual Studio. Moim zdecydowanym zaleceniem jest ustawienie prawdziwych zakończeń linii. I zrób to tak wcześnie, jak to możliwe, przez cały okres istnienia swojego repozytorium.

W związku z tym NIENAWIDZĘ, że Git zmienia moje zakończenia linii. Kontrola źródła powinna tylko zapisywać i pobierać pracę, którą wykonuję, NIE powinna jej modyfikować. Zawsze. Ale tak jest.

Co stanie się, jeśli nie ustawisz każdego programisty na true, to JEDEN programista ostatecznie ustawi się na true. Spowoduje to zmianę końców linii wszystkich plików na LF w repozytorium. A gdy użytkownicy ustawią na fałsz, to sprawdzą, Visual Studio ostrzeże Cię i poprosi o ich zmianę. Będziesz miał 2 rzeczy, które dzieją się bardzo szybko. Po pierwsze, będziesz otrzymywać coraz więcej takich ostrzeżeń, im większy zespół, tym więcej dostaniesz. Drugą i najgorszą rzeczą jest to, że pokaże, że każda linia każdego zmodyfikowanego pliku została zmieniona (ponieważ zakończenia linii każdej linii zostaną zmienione przez prawdziwego faceta). W końcu nie będzie już można niezawodnie śledzić zmian w repozytorium. O DUŻO łatwiej i czystiej jest, aby wszyscy trzymali się prawdy, niż starać się, aby wszyscy byli fałszywi. Jakkolwiek okropne jest życie z faktem, że zaufana kontrola źródła robi coś, czego nie powinna. Zawsze.

Aktualizacja 2 :

Wygląda na to, że Xcode 9 ma „funkcję” polegającą na ignorowaniu bieżących zakończeń linii i zamiast tego po prostu użyj domyślnego ustawienia zakończenia linii podczas wstawiania linii do pliku, co powoduje, że pliki mają mieszane zakończenia linii.

Jestem prawie pewien, że ten błąd nie istniał w Xcode 7; nie jestem pewien co do Xcode 8. Dobrą wiadomością jest to, że wydaje się być naprawiony w Xcode 10.

W czasie, gdy istniał, ten błąd powodował niewielką wesołość w bazie kodu, do której odwołuję się w pytaniu (które do dziś używa autocrlf=false), i doprowadził do wielu komunikatów o zatwierdzeniu „EOL”, a ostatecznie do napisania napisu „git pre-commithook” w celu sprawdzenia za / zapobieganie wprowadzaniu mieszanych zakończeń linii.

Aktualizacja :

Uwaga: Jak zauważył VonC, począwszy od Git 2,8, markery scalania będzie nie wprowadzać stylu Unix line-zakończeń do pliku Windows stylu .

Oryginał :

Jednym z drobnych problemów, które zauważyłem w tej konfiguracji, jest to, że gdy występują konflikty scalania, linie git dodaje, aby zaznaczyć, że różnice nie mają zakończeń linii systemu Windows, nawet jeśli ma to miejsce w pozostałej części pliku, i możesz skończyć z plikiem z mieszanymi zakończeniami linii, np .:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Nie powoduje to żadnych problemów (wyobrażam sobie, że każde narzędzie, które poradzi sobie z obydwoma rodzajami zakończeń linii, poradzi sobie również z mieszanymi zakończeniami linii - z pewnością wszystkie te, których używamy, to robi), ale należy o tym pamiętać.

Inną rzeczą, którą ^* odkryliśmy, jest to, że podczas git diffprzeglądania zmian w pliku z zakończeniami linii systemu Windows, dodane linie wyświetlają zwroty karetki, a zatem:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* To naprawdę nie zasługuje na określenie: „problem”.}