Git, dodawanie plików do repozytorium daje fatalny błąd dla LF -> CRLF

Question

Jestem nowy dla git i potrzebuję pomocy. Używam msysgit w systemie Windows.

Kiedy wykonać polecenie git add [folderName] otrzymuję odpowiedź:

fatal: LF would be replaced by CRLF in [.css file or .js file] 

a następnie, jeśli starają się zrobić popełnić nic się nie dzieje.

$ git commit 
# On branch master 
# 
# Initial commit 
# 
# Untracked files: 
# (use "git add <file>..." to include in what will be committed) 
# 
#  so01/ 
nothing added to commit but untracked files present (use "git add" to track) 

Niektóre z tych plików css/js zostały pobrane z sieci, więc sądzę, że właśnie dlatego mają LF. Po otwarciu pliku i wycięciu/wklejeniu zawartości, pojawia się błąd w następnym pliku i tak dalej.

Każda pomoc będzie mile widziane.

Edit

Ustawianie core.autocrlf false wydaje się rozwiązać ten problem, ale czytałem na wielu stanowiskach nie ustawić tę opcję na wartość false.

Czy ktoś może wskazać mi, gdzie mogę się dowiedzieć, jakie problemy mogą pojawić się w tej sytuacji?

Answer 1

Ufaj redaktorom kodu, aby manipulowali zakończeniami linii. Auto crlf powinno być fałszywe. Nie pozwól, aby kontrola nad źródłami stała się zbyt inteligentna. Jeśli nie potrzebujesz swojego narzędzia kontroli źródła, aby zmienić zakończenia linii, nie rób tego. To będzie bolało.

Aby powtórzyć z zaakceptowanej odpowiedzi: "Jeśli nie widzisz konkretnego leczenia, które musi radzić sobie z natywnym eol, lepiej jest pozostawić autocrlf na false".

także z książki progit na końcu sekcji dotyczącej autocrlf:

„Jeśli jesteś programistą systemu Windows robi Windows tylko projekt, można wyłączyć tę funkcję, nagrywanie powraca przewozu w repozytorium przez ustawienie wartości config false”

Jedyna pomoc, jaką mogę dać jest to, że jeśli wziąć inną trasą, zapoznać się z vim -b który pokaże znaki specjalne, takie jak CR w msysgit i git show HEAD:path/to/your/file.txt który powinien pokazać plik w taki sposób, w jaki git go zapisał.

Ustaw core.whitespace cr-at-eol, aby łaty i różnice nie podświetlały CR jako możliwego, problematycznego spacji.

Nie warte kłopotów. Przechowuj tak, jak jest.

Answer 2

Problem prawdopodobnie występuje, ponieważ ustawiono Git do przechowywania plików wewnętrznie z crlf z ustawieniem core.eol. Po dodaniu pliku Git ostrzega, że ​​zmieni go na format wewnętrzny.

Git działa najlepiej z zakończeniami linii lf, więc jeśli to możliwe, zawsze pracuj z core.eol = lf.

To powinno wyjaśnić kiedy używać core.autocrlf, Why should I use core.autocrlf=true in Git?

Można również użyć core.safecrlf. Sprawdź git config --help, aby uzyskać szczegółowe informacje na temat ustawień.

Answer 3

Bardzo nowość w tym ustawieniu core.autocrlf na false nie miała dla mnie większego sensu. Więc dla innych początkujących, przejdź do pliku konfiguracyjnego w twoim folderze .git i dodaj:

[core] 
    autocrlf = false 

pod nagłówkiem [core].

Answer 4

Autodetekcja git formatów działa całkiem dobrze. Dlatego core.autocrlf=true to naprawdę dobry pomysł na Windows.

Mówiąc git config --global core.safecrlf=false mówi git: Hej, proszę przekonwertować moje błędne końca linii (LF), aby zakończeń linii Windows (CRLF) i nie przeszkadza mi to.

Dlatego należy naprawdę wyłączyć core.safecrlf.

Dłuższa odpowiedź na: https://stackoverflow.com/a/15471083/873282