Jak zmienić ustawienia zakończenia linii


581

Czy istnieje plik lub menu, które pozwolą mi zmienić ustawienia dotyczące postępowania z zakończeniami linii?

Czytam, są 3 opcje:

  1. Kasa w stylu Windows, zatwierdzanie w stylu Uniksa

    Podczas sprawdzania plików tekstowych Git konwertuje LF na CRLF. Podczas zatwierdzania plików tekstowych CRLF zostanie przekonwertowany na LF. W przypadku projektów wieloplatformowych jest to zalecane ustawienie w systemie Windows („core.autocrlf” jest ustawiony na „true”)

  2. Kwestia jak jest, zatwierdza styl uniksowy

    Podczas sprawdzania plików tekstowych Git nie wykona żadnej konwersji. Podczas zatwierdzania plików tekstowych CRLF zostanie przekonwertowany na LF. W przypadku projektów wieloplatformowych jest to zalecane ustawienie w systemie Unix („core.autocrlf” jest ustawiony na „input”).

  3. Kasa jak jest, zatwierdza jak jest

    Git nie wykona żadnych konwersji podczas sprawdzania lub zatwierdzania plików tekstowych. Wybranie tej opcji nie jest zalecane w przypadku projektów wieloplatformowych („core.autocrlf” jest ustawiony na „false”)



3
Który z nich jest domyślny?
Stephen

2
Nieważne, wygląda na to, że domyślna jest prawda, co moim zdaniem jest właściwe.
Stephen

18
Uważam, że trzecia opcja działa lepiej. W przeciwnym razie często zdarza mi się, że edytuję skrypty wsadowe i sh na tej samej platformie (Windows / Linux), a następnie zatwierdzam je, a Git automatycznie „naprawia” zakończenia linii dla jednej platformy ... Nie, wolę być samodzielnym świadomy zakończeń linii i zatwierdzaj / sprawdzaj je dokładnie takimi, jakie są.
JustAMartin,

1
@Neutrino Chciałbym, żeby to była prawda, ale jednym z przykładów IDE, które miesza się z twoimi zakończeniami linii (i nie oferuje rozsądnej opcji konfiguracji, aby to wyłączyć) jest Visual Studio.
Cássio Renan

Odpowiedzi:


527

Normalny sposób to kontrolować git config

Na przykład

git config --global core.autocrlf true

Aby uzyskać szczegółowe informacje, przewiń w dół do tego linku do Pro Git do sekcji o nazwie „core.autocrlf”


Jeśli chcesz wiedzieć, w jakim pliku jest zapisany, możesz uruchomić polecenie:

git config --global --edit

globalny plik konfiguracyjny git powinien otworzyć się w edytorze tekstów i można zobaczyć, skąd ten plik został załadowany.


17
truelub falsesą tylko dwie opcje, instalator ma trzy
qwertymk

49
inputjest trzecią opcją (jak podano w linku, który podałem). 3 opcje to true| false| input
CodingWithSpike

2
Oto kolejne dobre pytanie SO na ten temat: stackoverflow.com/questions/3206843/…
CodingWithSpike

31
W rzeczywistości, jeśli ponownie przeczytasz swoje pytanie, w skopiowanych / wklejonych fragmentach: "1 ... ("core.autocrlf" is set to "true") ... 2 ... ("core.autocrlf" is set to "input") ... 3 ... ("core.autocrlf" is set to "false")"więc w zasadzie odpowiedziałeś na własne pytanie? :)
CodingWithSpike

2
To stary sposób na obejście tego. Spójrz na plik .gitattributes.
eftshift0

176

Format zakończenia linii używany w systemie operacyjnym

  • Windows: para CR(Carriage Return \r) i LF(LineFeed \n)
  • OSX, Linux: LF(LineFeed \n)

Możemy skonfigurować git, aby automatycznie poprawiał formaty zakończenia linii dla każdego systemu operacyjnego na dwa sposoby.

  1. Globalna konfiguracja Git
  2. Użyj .gitattributespliku

Konfiguracja globalna

W systemie Linux / OSX
git config --global core.autocrlf input

Będzie to naprawić każdy CRLFdoLF podczas popełniania.

W systemie Windows
git config --global core.autocrlf true

Zapewni to, że podczas kasowania w systemie Windows wszystkie LFzostaną przekonwertowane naCRLF

Plik .gitattributes

Dobrym pomysłem jest przechowywanie .gitattributespliku, ponieważ nie chcemy oczekiwać, że wszyscy w naszym zespole ustawią swoją konfigurację. Plik ten powinien znajdować się w ścieżce katalogu głównego repozytorium, a jeśli taki istnieje, git go przestrzega.

* text=auto

Spowoduje to potraktowanie wszystkich plików jako plików tekstowych i konwersję do wiersza systemu operacyjnego kończącego się przy kasie i powrót do LFzatwierdzenia automatycznie. Jeśli chcesz powiedzieć wprost, użyj

* text eol=crlf
* text eol=lf

Pierwszy służy do kasy, a drugi do zatwierdzenia.

*.jpg binary

Traktuj wszystkie .jpgobrazy jako pliki binarne, niezależnie od ścieżki. Dlatego nie jest wymagana konwersja.

Lub możesz dodać kwalifikatory ścieżki:

my_path/**/*.jpg binary

3
A co z OS X, który używa CRsamego (powrót karetki)?
jww

23
Starsze MacOS (czyli MacOS 9 i wcześniejsze) są używane CRsamodzielnie, ale OS X na ogół używa LF.
Zachary Ware

2
Czy mogę użyć * text eol=lfdwa razy, aby mieć kasę LFw systemie Windows?
mbomb007,

1
Zgodnie z ustawieniami dokumentacji gitattributes* text=auto pozwala git zdecydować, czy treść jest tekstowa, czy nie. Wymuszanie, aby wszystkie pliki były tekstem, powinno być * texttylko.
Adrian W

Jak ustawić eol=crpliki w systemie Mac OS 9 i innych starszych platformach?
NobleUplift,

36

Aby znaleźć rozwiązanie do ustawiania repozytorium, które można rozpowszechniać wśród wszystkich programistów, sprawdź atrybut tekstowy w pliku .gitattributes . W ten sposób programiści nie muszą ręcznie ustawiać własnych zakończeń linii w repozytorium, a ponieważ różne repozytoria mogą mieć różne style zakończenia linii, globalny core.autocrlf nie jest najlepszy, przynajmniej moim zdaniem.

Na przykład cofnięcie ustawienia tego atrybutu na danej ścieżce [ . - tekst] zmusi gita, aby nie dotykał końcówek linii podczas meldowania się i wymeldowywania. Moim zdaniem jest to najlepsze zachowanie, ponieważ większość współczesnych edytorów tekstu może obsługiwać oba typy zakończeń linii. Ponadto, jeśli jako programista nadal chcesz przeprowadzić konwersję kończącą linię podczas meldowania, nadal możesz ustawić ścieżkę, aby dopasować określone pliki lub ustawić atrybut eol (w .gitattributes) w repozytorium.

Zobacz także pokrewny post, który bardziej szczegółowo opisuje plik .gitattributes i atrybut tekstowy: Jaka jest najlepsza strategia obsługi CRLF (powrót karetki, przesunięcie wiersza) w Git?


. - textdaje is not a valid attribute name: .gitattributes:1proszę umieścićcat .gitattributes
jangorecki

3

Dla mnie, jaka sztuczka polegała na uruchomieniu polecenia

git config auto.crlf false

W folderze projektu chciałem go specjalnie dla jednego projektu.

To polecenie zmieniło plik w ścieżce {nazwa_projektu} /. Git / config (fyi .git to ukryty folder) poprzez dodanie wierszy

[auto]
    crlf = false

na końcu pliku. Przypuszczam, że zmiana pliku również działa tak samo.


1

Jeśli chcesz przekonwertować formaty plików, które zostały zmienione na format UNIX, z formatu PC.

(1) Musisz ponownie zainstalować GIT żółwia i w sekcji „Konwersja kończąca linię” upewnij się, że wybrałeś opcję „Sprawdź jak jest - sprawdź jak jest”.

(2) i zachowaj pozostałe konfiguracje bez zmian.

(3) po zakończeniu instalacji

(4) zapisz wszystkie rozszerzenia plików przekonwertowane do formatu UNIX na plik tekstowy (extensions.txt).

ex:*.dsp
   *.dsw

(5) skopiuj plik do swojego klonu Uruchom następujące polecenie w GITBASH

while read -r a;
do
find . -type f -name "$a" -exec dos2unix {} \;
done<extension.txt
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.