Próbowałem zatwierdzić pliki z liniami kończącymi CRLF, ale nie powiodło się.

Cały dzień pracy spędziłem na komputerze z systemem Windows, próbując różnych strategii i prawie byłem zmuszony przestać używać Gita, a zamiast tego spróbować Mercurial .

Udostępnij tylko jedną najlepszą praktykę na odpowiedź.

Prawie cztery lata po zadaniu tego pytania w końcu znalazłem odpowiedź, która całkowicie mnie satysfakcjonuje !

Zobacz szczegóły w github: przewodnik pomocy Jak radzić sobie z zakończeniami linii .

Git pozwala ustawić właściwości zakończenia linii dla repo bezpośrednio za pomocą atrybutu text w .gitattributespliku. Ten plik jest przypisany do repozytorium i zastępuje core.autocrlfustawienie, umożliwiając zapewnienie spójnego zachowania wszystkim użytkownikom, niezależnie od ich ustawień git.

A zatem

Zaletą tego jest to, że konfiguracja na końcu linii przemieszcza się teraz z repozytorium i nie musisz się martwić, czy współpracownicy mają odpowiednie ustawienia globalne.

Oto przykład .gitattributespliku

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

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Istnieje wygodny zbiór gotowych do użycia plików .gitattributes dla najpopularniejszych języków programowania. Dobrze jest zacząć.

Po utworzeniu lub dostosowaniu .gitattributesnależy wykonać ponowną normalizację zakończeń linii raz na zawsze .

Pamiętaj, że aplikacja GitHub Desktop może zasugerować i utworzyć .gitattributesplik po otwarciu repozytorium Git projektu w aplikacji. Aby spróbować, kliknij ikonę koła zębatego (w prawym górnym rogu)> Ustawienia repozytorium ...> Zakończenia linii i atrybuty. Zostaniesz poproszony o dodanie zalecanego, .gitattributesa jeśli się zgodzisz, aplikacja wykona również normalizację wszystkich plików w repozytorium.

Wreszcie artykuł Mind the End of Your Line zawiera więcej informacji i wyjaśnia, w jaki sposób Git ewoluował w omawianych sprawach. Uważam to za konieczne czytanie .

Prawdopodobnie masz w swoim zespole użytkowników, którzy używają EGit lub JGit (narzędzia takie jak Eclipse i TeamCity używają ich) do zatwierdzania swoich zmian. Nie masz szczęścia, jak wyjaśnił @gatinueta w komentarzach do tej odpowiedzi:

To ustawienie nie zadowoli Cię całkowicie, jeśli masz w zespole osoby pracujące z Egit lub JGit, ponieważ narzędzia te po prostu zignorują atrybuty .git i z przyjemnością sprawdzą pliki CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

Jedną sztuczką może być zmuszenie ich do wprowadzenia zmian w innym kliencie, powiedzmy SourceTree . Nasz zespół wolał wtedy to narzędzie od EGit Eclipse w wielu przypadkach użycia.

Kto powiedział, że oprogramowanie jest łatwe? : - /

Nie przekształcaj zakończeń linii. Interpretacja danych nie jest zadaniem VCS - wystarczy je zapisać i zaktualizować. Każdy nowoczesny edytor tekstu może odczytać oba rodzaje zakończeń linii.

Prawie zawsze chcesz, autocrlf=inputchyba że naprawdę wiesz, co robisz.

Dodatkowy kontekst poniżej:

Powinno tak być, core.autocrlf=truejeśli podoba Ci się zakończenie DOS lub core.autocrlf=inputjeśli wolisz unix-newline. W obu przypadkach twoje repozytorium Git będzie miało tylko LF, co jest właściwą rzeczą. Jedyny argument przemawiał za core.autocrlf=falsetym, że automatyczna heurystyka może nieprawidłowo wykryć niektóre pliki binarne jako tekst, a następnie twój kafelek zostanie uszkodzony. Tak więc core.safecrlfwprowadzono opcję ostrzegania użytkownika o nieodwracalnej zmianie. W rzeczywistości istnieją dwie możliwości nieodwracalnych zmian - mieszane zakończenie linii w pliku tekstowym, w tej normalizacji jest pożądane, więc to ostrzeżenie można zignorować lub (bardzo mało prawdopodobne), że Git nieprawidłowo wykrył twój plik binarny jako tekst. Następnie musisz użyć atrybutów, aby powiedzieć Gitowi, że ten plik jest binarny.

Powyższy akapit został pierwotnie pobrany z wątku na gmane.org, ale od tamtej pory został usunięty.

Dwie alternatywne strategie pozwalające uzyskać spójność zakończeń linii w środowiskach mieszanych (Microsoft + Linux + Mac):

A. Konfiguracja globalna dla wszystkich repozytoriów

1) Konwertuj wszystko na jeden format

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Zestaw core.autocrlfdo inputna Linux / Unix lub truena MS Windows (repozytorium lub globalne)

git config --global core.autocrlf input

3) [Opcjonalnie] ustaw core.safecrlfna true(aby zatrzymać) lub warn(aby śpiewać :), aby dodać dodatkową ochronę, porównując, czy odwrócona transformacja nowego wiersza da ten sam plik

git config --global core.safecrlf true

B. Lub według konfiguracji repozytorium

1) Konwertuj wszystko na jeden format

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) dodaj .gitattributesplik do swojego repozytorium

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Nie martw się o swoje pliki binarne - Git powinien być wystarczająco inteligentny.

Więcej informacji o zmiennych safecrlf / autocrlf

Spróbuj ustawić core.autocrlfopcję konfiguracji na true. Zobacz także core.safecrlfopcję.

Właściwie to wygląda na to, że core.safecrlfmoże być już ustawione w twoim repozytorium, ponieważ (moje wyróżnienie):

Jeśli tak nie jest w przypadku bieżącego ustawienia core.autocrlf, git odrzuci plik .

W takim przypadku możesz sprawdzić, czy edytor tekstu jest skonfigurowany do spójnego używania zakończeń linii. Prawdopodobnie wystąpią problemy, jeśli plik tekstowy zawiera mieszaninę zakończeń linii LF i CRLF.

Wreszcie, uważam, że zalecenie, aby po prostu „użyć tego, co otrzymałeś” i użyć linii zakończonych LF w systemie Windows spowoduje więcej problemów niż rozwiązuje. Git ma powyższe opcje, aby rozsądnie traktować zakończenia linii, więc warto z nich korzystać.

Użycie core.autocrlf=falsezatrzymało oznaczanie wszystkich plików jako zaktualizowane, gdy tylko je sprawdziłem w projekcie Visual Studio 2010 . Pozostali dwaj członkowie zespołu programistycznego również używają systemów Windows, więc mieszane środowisko nie wchodziło w grę, ale ustawienia domyślne dostarczone z repozytorium zawsze oznaczały wszystkie pliki jako zaktualizowane natychmiast po klonowaniu.

Wydaje mi się, że najważniejsze jest ustalenie, jakie ustawienie CRLF działa w twoim środowisku. Zwłaszcza, że ​​w wielu innych repozytoriach w naszym systemie Linux ustawienie pudełek autocrlf = truedaje lepsze wyniki.

Ponad 20 lat później nadal mamy do czynienia z różnicami w końcowych liniach między systemami operacyjnymi ... smutne.

Są to dwie opcje dla użytkowników Windows i Visual Studio, którzy współużytkują kod z użytkownikami komputerów Mac lub Linux . Aby uzyskać szczegółowe wyjaśnienie, przeczytaj instrukcję gitattributes .

* tekst = auto

W .gitattributespliku repozytorium dodaj:

*   text=auto

Spowoduje to normalizację wszystkich plików z LFzakończeniami linii w repozytorium.

W zależności od systemu operacyjnego ( core.eolustawienia) pliki w drzewie roboczym zostaną znormalizowane do LFsystemów opartych na Uniksie lub CRLFsystemów Windows.

Jest to konfiguracja używana przez repozytorium Microsoft .NET .

Przykład:

Hello\r\nWorld

Będzie znormalizowany w repozytorium zawsze jako:

Hello\nWorld

Podczas realizacji transakcji działające drzewo w systemie Windows zostanie przekonwertowane na:

Hello\r\nWorld

Przy kasie działające drzewo w Macu pozostanie jako:

Hello\nWorld

Uwaga: jeśli Twoje repozytorium zawiera już pliki, które nie są znormalizowane, git statuspokażą te pliki jako całkowicie zmodyfikowane przy następnym wprowadzeniu jakichkolwiek zmian, a innym użytkownikom może być problem z późniejszym scaleniem. Zobacz odświeżanie repozytorium po zmianie zakończenia linii, aby uzyskać więcej informacji.

core.autocrlf = true

Jeśli nie textjest określony w .gitattributespliku, Git używa core.autocrlfzmiennej konfiguracyjnej do ustalenia, czy plik powinien zostać przekonwertowany.

Dla użytkowników systemu Windows git config --global core.autocrlf truejest świetną opcją, ponieważ:

• Pliki są znormalizowane do LFzakończeń linii tylko po dodaniu do repozytorium. Jeśli w repozytorium znajdują się pliki, które nie są znormalizowane, to ustawienie ich nie dotknie.
• Wszystkie pliki tekstowe są konwertowane na CRLFzakończenia linii w katalogu roboczym.

Problem z tym podejściem polega na tym, że:

• Jeśli jesteś użytkownikiem systemu Windows autocrlf = input, zobaczysz kilka plików z LFzakończeniami linii. Nie stanowi to zagrożenia dla reszty zespołu, ponieważ twoje zobowiązania nadal będą znormalizowane z LFzakończeniami linii.
• Jeśli jesteś użytkownikiem systemu Windows core.autocrlf = false, zobaczysz kilka plików z LFzakończeniami linii i możesz wprowadzić pliki z CRLFzakończeniami linii do repozytorium.
• Większość użytkowników komputerów Mac używa autocrlf = inputi może pobierać pliki z CRLFkońcówkami, prawdopodobnie od użytkowników systemu Windows z core.autocrlf = false.

--- UPDATE 3 --- (nie koliduje z UPDATE 2)

Biorąc pod uwagę przypadek, w którym użytkownicy systemu Windows wolą pracować, CRLFa użytkownicy systemu Linux / Mac wolą pracować nad LFplikami tekstowymi. Udzielenie odpowiedzi z perspektywy opiekuna repozytorium :

Dla mnie najlepszą strategią (mniej problemów do rozwiązania) jest: zachowaj wszystkie pliki tekstowe z LFwewnętrznym repozytorium git, nawet jeśli pracujesz nad projektem tylko dla systemu Windows. Następnie daj klientom swobodę pracy nad stylem końca preferencji , pod warunkiem, że wybiorą core.autocrlfwartość właściwości, która będzie szanować twoją strategię (LF przy repo) podczas przemieszczania plików do zatwierdzenia.

Inscenizacja jest tym, co wiele osób myli, próbując zrozumieć, jak działają strategie nowej linii . Przed wybraniem właściwej wartości core.autocrlfwłaściwości należy koniecznie zrozumieć następujące punkty :

• Dodanie pliku tekstowego dla commit ( wystawiając go) to jak kopiowanie pliku do innego miejsca wewnątrz .git/podkatalogu z przekonwertowane line-zakończeń (w zależności od core.autocrlfwartości na swojej konfiguracji klienta). Wszystko to odbywa się lokalnie.
• ustawienie core.autocrlfjest jak udzielenie odpowiedzi na pytanie (dokładnie to samo pytanie na wszystkich systemach operacyjnych):
  • „Czy git-client a. Konwertuje LF-na-CRLF podczas sprawdzania (wyciągania) zmian repo ze zdalnego lub b. Konwertuje CRLF-na-LF podczas dodawania pliku do zatwierdzenia? ” I możliwe odpowiedzi (wartości) są:
  • false:„ nie rób nic z powyższych ”,
  • input:„ Nie tylko b ”
  • true: „ zrób aib ”
  • zwróć uwagę, że NIE MA „ rób tylko ”

na szczęście

• Domyślne ustawienia klienta git (windows core.autocrlf: true:, linux / mac:) core.autocrlf: falsebędą zgodne ze strategią repo tylko LF .
  Znaczenie : klienci Windows domyślnie przekonwertują na CRLF podczas sprawdzania repozytorium i konwertują na LF podczas dodawania do zatwierdzenia. Klienci Linuksa domyślnie nie wykonują żadnych konwersji. Teoretycznie zachowuje to tylko twoje repozytorium.

Niestety:

• Mogą istnieć klienci GUI, którzy nie przestrzegają core.autocrlfwartości git
• Mogą istnieć ludzie, którzy nie używają wartości, aby szanować twoją strategię repo. Np. Używają core.autocrlf=falsei dodają plik z CRLF do zatwierdzenia.

Aby wykryć ASAP inne niż tekstowe pliki tekstowe zatwierdzone przez powyższych klientów , możesz postępować zgodnie z opisem w --- aktualizacja 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, na kliencie skompilowanym przy użyciu: --with-libpcreflag)

I tu jest haczyk: . Jako opiekun repo przechowuję plik, git.autocrlf=inputdzięki czemu mogę naprawić wszelkie nieprawidłowo popełnione pliki, dodając je ponownie w celu zatwierdzenia. I dostarczam tekst zatwierdzenia: „Naprawianie nieprawidłowo zatwierdzonych plików”.

O ile .gitattributesjest to uzasadnione. Nie liczę na to, ponieważ jest więcej klientów interfejsu użytkownika, którzy tego nie rozumieją. Używam go tylko do udzielania wskazówek dla plików tekstowych i binarnych, a może oznaczam wyjątkowe pliki, które powinny wszędzie mieć te same zakończenia linii:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Pytanie: Ale dlaczego w ogóle interesuje nas strategia obsługi nowego wiersza?

Odpowiedź: Aby uniknąć zatwierdzenia zmiany jednej litery, wyświetlaj się jako zmiana 5000-wierszowa , tylko dlatego, że klient, który dokonał zmiany, automatycznie przekonwertował pełny plik z crlf na lf (lub odwrotnie) przed dodaniem go do zatwierdzenia. Może to być dość bolesne, gdy w grę wchodzi rozwiązanie konfliktu . Lub może w niektórych przypadkach być przyczyną nierozsądnych konfliktów.

--- AKTUALIZACJA 2 ---

Awarie klienta git będą działać w większości przypadków. Nawet jeśli masz tylko klientów Windows, tylko Linux lub oba. To są:

• windows: core.autocrlf=true oznacza konwersję linii do CRLF przy kasie i konwersję linii do LF podczas dodawania plików.
• linux: core.autocrlf=input oznacza, że ​​nie należy konwertować linii przy kasie (nie ma takiej potrzeby, ponieważ oczekuje się, że pliki zostaną zatwierdzone w LF) i konwertuj linie do LF (jeśli to konieczne) podczas dodawania plików. ( - update3 - : Wydaje się, że jest to falsedomyślnie, ale znowu jest w porządku)

Właściwość można ustawić w różnych zakresach. Sugerowałbym wyraźne ustawienie --globalzakresu, aby uniknąć niektórych problemów IDE opisanych na końcu.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Również zdecydowanie odradzałbym używanie w systemie Windows git config --global core.autocrlf false (jeśli masz tylko klientów Windows) w przeciwieństwie do tego, co proponuje się w dokumentacji git . Ustawienie wartości false spowoduje zatwierdzenie plików z CRLF w repozytorium. Ale tak naprawdę nie ma powodu. Nigdy nie wiadomo, czy będziesz musiał udostępnić projekt użytkownikom Linuksa. Dodatkowo jest to jeden dodatkowy krok dla każdego klienta, który dołącza do projektu zamiast korzystać z ustawień domyślnych.

Teraz w przypadku niektórych specjalnych przypadków plików (np. *.bat *.sh), Które chcesz, aby zostały wyewidencjonowane za pomocą LF lub CRLF, możesz użyć.gitattributes

Podsumowując, dla mnie najlepszą praktyką jest:

• Upewnij się, że każdy plik niebinarny jest zatwierdzony przez LF na git repo (zachowanie domyślne).
• Użyj tego polecenia, aby upewnić się, że żadne pliki nie są zatwierdzone za pomocą CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Uwaga: w systemach Windows klienci działają tylko przez, git-basha na klientach z systemem Linux tylko, jeśli są skompilowani przy użyciu --with-libpcrein ./configure).
• Jeśli znajdziesz takie pliki, wykonując powyższe polecenie, popraw je. Dotyczy to (przynajmniej na Linuksie):
  • zestaw core.autocrlf=input( --- aktualizacja 3 - )
  • zmień plik
  • cofnij zmianę (plik jest nadal wyświetlany jako zmieniony)
  • popełnij to
• Używaj tylko absolutnego minimum .gitattributes
• Poinstruuj użytkowników, aby ustawili core.autocrlfwyżej opisane wartości domyślne.
• Nie licz 100% na obecność .gitattributes. git-klienci IDE mogą je ignorować lub traktować inaczej.

Jak już wspomniano, niektóre atrybuty git można dodać:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Myślę, że istnieją inne bezpieczne opcje .gitattributeszamiast używania automatycznego wykrywania plików binarnych:

• -text(np. dla plików *.ziplub *.jpg: nie będzie traktowany jak tekst. W związku z tym nie będą podejmowane próby konwersji na końcu linii. Różnice mogą być możliwe w programach do konwersji)
• text !eol(np *.java, *.html:.. Traktowana jako tekst, ale preferencji styl EOL nie jest tak ustawiony ustawienie klient jest używany)
• -text -diff -merge(np. dla *.hugefile: Nie jest traktowany jako tekst. Brak możliwości porównania / scalenia)

--- POPRZEDNIA AKTUALIZACJA ---

Jeden bolesny przykład klienta, który nieprawidłowo zatwierdza pliki:

netbeans 8.2 (w systemie Windows), nieprawidłowo zatwierdza wszystkie pliki tekstowe z CRLF-ami, chyba że jawnie ustawisz core.autocrlfjako globalny . Jest to sprzeczne ze standardowym zachowaniem klienta git i powoduje wiele problemów później, podczas aktualizacji / scalania. To sprawia, że ​​niektóre pliki wyglądają inaczej (chociaż nie są) nawet po przywróceniu .
To samo zachowanie w netbeansie dzieje się, nawet jeśli poprawnie dodałeś .gitattributesprojekt.

Użycie następującego polecenia po zatwierdzeniu pomoże przynajmniej wcześnie wykryć, czy w repozytorium git występują problemy z zakończeniem linii: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Spędziłem godziny, aby wymyślić jak najlepsze wykorzystanie .gitattributes, aby w końcu uświadomić sobie, że nie mogę na to liczyć.
Niestety, dopóki istnieją edytory oparte na JGit (które nie mogą .gitattributespoprawnie obsługiwać ), bezpiecznym rozwiązaniem jest wymuszanie LF wszędzie, nawet na poziomie edytora.

Użyj następujących anti-CRLFśrodków dezynfekujących.

• klienci Windows / Linux: core.autocrlf=input

• popełnił .gitattributes: * text=auto eol=lf

• commit .editorconfig( http://editorconfig.org/ ), który jest rodzajem znormalizowanego formatu, w połączeniu z wtyczkami edytora:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

To tylko rozwiązanie obejścia :

W normalnych przypadkach użyj rozwiązań dostarczonych z git. Te działają świetnie w większości przypadków. Skorzystaj z LF, jeśli udostępniasz programowanie w systemach Windows i Unix, ustawiając .gitattributes .

W moim przypadku było> 10 programistów rozwijających projekt w systemie Windows. Ten projekt został zaewidencjonowany za pomocą CRLF i nie było opcji wymuszania na LF.

Niektóre ustawienia zostały zapisane wewnętrznie na moim komputerze bez żadnego wpływu na format LF; dlatego niektóre pliki zostały globalnie zmienione na LF przy każdej małej zmianie pliku.

Moje rozwiązanie:

Komputery z systemem Windows: pozwól, by wszystko było takie, jakie jest. Nie przejmuj się niczym, ponieważ jesteś domyślnym programistą Windows „samotnego wilka” i musisz sobie z tym poradzić w następujący sposób: „Nie ma innego systemu na całym świecie, prawda?”

Maszyny uniksowe

1. Dodaj następujące wiersze do [alias]sekcji konfiguracji . To polecenie wyświetla listę wszystkich zmienionych (tj. Zmodyfikowanych / nowych) plików:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Konwertuj wszystkie zmienione pliki do formatu dos:

   unix2dos $(git lc)

3. Opcjonalnie ...

   1. Utwórz git hook dla tej akcji, aby zautomatyzować ten proces

   2. Użyj params i dołącz go i zmodyfikuj grepfunkcję, aby dopasować tylko określone nazwy plików, np .:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Zachęcamy do uczynienia go jeszcze wygodniejszym za pomocą dodatkowego skrótu:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... i odpal przekonwertowane rzeczy, pisząc

      git c2dos