Rozwiązanie CRLF dla Git (znaki końca linii w Windows)

W Windows końce linii w plikach z tekstem zapisywane są jako dwa znaki CRLF a np. w Linuksie jest to tylko LF. W kodzie wygląda to:

"\r\n" // windows
"\n" // linux

(Btw pisanie w kodzie powyższych stałych jest słabe, mamy przecież Environment.NewLine)

Gdy mamy pliki z kodem pod kontrolą wersji to zaczynają się kłopoty. Nagle okazuje się, że ktoś ma inne ustawienia i wszystkie pliki, które commitował mają zmieniane LF -> CRLF lub odwrotnie, wtedy dostajemy tzw. Wall of pink.

wall of pink, github for windows

Nic w kodzie się nie zmieniło

Podejście per projekt

Nie ma dobrego rozwiązania, temat opisuje Hanselman w You’re Just Another Carriage Return Line Feed In The Wall.

Ja korzystam z podejścia What’s the best CRLF handling strategy with git? Tworzymy plik .gitattribues (np GitHub for Windows tworzy za nas) z wpisami

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
...

i dokonujemy jednorazowej „re-normalizacji” na całym repozytorium. Gdy inni użytkownicy też tak zrobią to się nie pogryziemy 🙂

Efekt: nasze pliki na dysku będą się kończyć na CRLF (przed zmianą jak i po).

CRLF in file

W repozytorium przed zmianą było CRLF, a po zmianie będzie LF.

Podejście globalne


git config --global core.autocrlf true

Utworzy to w naszym globalnym .gitconfig:

[core]
autocrlf = true

Czy dotyczy to każdego?

„Prawie” każdego:

If you develop in a cave (…) the default settings in Git will suit you just fine. The rest of you, read on!

Github: Dealing with line endings

Mnie uderzył ten problem dzisiaj, ponieważ kiedyś, gdzieś kliknąłem i utworzył się plik .gitattributes. Później okazło się, że git reset –hard nie działa i wreszcie byłem zmuszony kompleksowo rozwiązać problem.

Reklamy
Ten wpis został opublikowany w kategorii Programowanie i oznaczony tagami , , , . Dodaj zakładkę do bezpośredniego odnośnika.