Git ersetzt LF durch CRLF

Ausführen von git auf einem Windows XP-Computer mit bash. Ich habe mein Projekt aus SVN exportiert und dann ein nacktes Repository geklont.

Ich habe dann den Export in das Bare-Repositorys-Verzeichnis eingefügt und Folgendes ausgeführt:

git add -A

Ich habe dann eine Liste mit Nachrichten erhalten, die besagen:

LF wird durch CRLF ersetzt

Was sind die Konsequenzen dieser Konvertierung? Dies ist eine .NET-Lösung in Visual Studio.

Diese Meldungen sind auf einen falschen Standardwert von core.autocrlfunter Windows zurückzuführen.

Das Konzept von autocrlfbesteht darin, Zeilenendkonvertierungen transparent zu handhaben. Und das tut es!

Schlechte Nachrichten : Der Wert muss manuell konfiguriert werden.
Gute Nachricht : Es sollte nur EINMAL pro Git-Installation durchgeführt werden (pro Projekteinstellung ist auch möglich).

Wie autocrlffunktioniert :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Hier crlf= Win-Style-End-of-Line-Marker, lf= Unix-Style (und Mac OSX).

(Pre-Osx ist crfür keine der drei oben genannten Optionen betroffen)

Wann wird diese Warnung angezeigt (unter Windows)

    - autocrlf= truewenn Sie einen Unix-Stil lfin einer Ihrer Dateien haben (= RARELY),
    - autocrlf= inputwenn Sie einen Win-Stil crlfin einer Ihrer Dateien haben (= fast IMMER),
    - autocrlf= false- NIE!

Was bedeutet diese Warnung?

Die Warnung " LF wird durch CRLF ersetzt " besagt, dass Sie (mit autocrlf= true) Ihren LF im Unix-Stil nach dem Commit-Checkout-Zyklus verlieren (er wird durch CRLF im Windows-Stil ersetzt). Git erwartet nicht, dass Sie LF im Unix-Stil unter Windows verwenden.

Die Warnung " CRLF wird durch LF ersetzt " besagt, dass Sie (mit autocrlf= input) Ihre CRLF im Windows-Stil nach einem Commit-Checkout-Zyklus verlieren (sie wird durch LF im Unix-Stil ersetzt). Nicht inputunter Fenstern verwenden.

Ein weiterer Weg, um zu zeigen, wie es autocrlffunktioniert

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

Dabei ist x entweder CRLF (Windows-Stil) oder LF (Unix-Stil) und Pfeile stehen für

file to commit -> repository -> checked out file

Wie repariert man

Der Standardwert für core.autocrlfwird während der Git-Installation ausgewählt und in der systemweiten gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) gespeichert . Auch gibt es (Kaskadierung in der folgenden Reihenfolge):

   - "globale" (pro Benutzer) gitconfig befindet sich unter ~/.gitconfig, noch eine andere
   - "globale" (pro Benutzer) gitconfig bei $XDG_CONFIG_HOME/git/configoder $HOME/.config/git/configund
   - "lokale" (pro repo) gitconfig bei .git/configim Arbeitsverzeichnis.

Schreiben Sie also git config core.autocrlfin das Arbeitsverzeichnis, um den aktuell verwendeten Wert und zu überprüfen

   - autocrlf=falsezur systemweiten gitconfig hinzufügen # pro system lösung
   - git config --global core.autocrlf false            # pro benutzer lösung
   - git config --local core.autocrlf false              # pro projekt lösung

Warnungen
- git configEinstellungen können durch gitattributesEinstellungen überschrieben werden .
- Die crlf -> lfKonvertierung erfolgt nur beim Hinzufügen neuer Dateien. crlfDateien, die bereits im Repo vorhanden sind, sind nicht betroffen.

Moral (für Windows):
    - Verwenden Sie core.autocrlf=, truewenn Sie dieses Projekt auch unter Unix verwenden möchten (und Ihren Editor / Ihre IDE nicht für die Verwendung von Unix-Zeilenenden konfigurieren möchten).
    - Verwenden Sie core.autocrlf=, falsewenn Sie dieses Projekt nur unter Windows verwenden möchten ( oder Sie haben Ihren Editor / Ihre IDE so konfiguriert, dass Unix-Zeilenenden verwendet werden.
    - Verwenden Sie niemalscore.autocrlf =, es inputsei denn, Sie haben einen guten Grund dazu ( z. B. wenn Sie Unix-Dienstprogramme unter Windows verwenden oder wenn Sie auf Makefiles-Probleme stoßen).

PS Was ist bei der Installation von git für Windows zu wählen?
Wenn Sie keines Ihrer Projekte unter Unix verwenden möchten, stimmen Sie der ersten Standardoption nicht zu. Wählen Sie die dritte aus ( Checkout wie sie ist, Commit wie sie ist ). Sie werden diese Nachricht nicht sehen. Je.

PPS Meine persönliche Präferenz ist die Konfiguration des Editors / der IDE für die Verwendung von Endungen im Unix-Stil und die Einstellung core.autocrlfauf false.

Git hat drei Modi für den Umgang mit Zeilenenden:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Sie können den zu verwendenden Modus einstellen, indem Sie einen zusätzlichen Parameter von trueoder falsezur obigen Befehlszeile hinzufügen .

Wenn core.autocrlftrue festgelegt ist, bedeutet dies, dass jedes Mal, wenn Sie dem Git-Repo eine Datei hinzufügen, die Git für eine Textdatei hält, alle CRLF-Zeilenenden nur auf LF gesetzt werden, bevor sie im Commit gespeichert werden. Wann immer Sie git checkoutetwas tun, werden bei allen Textdateien automatisch die LF-Zeilenenden in CRLF-Endungen konvertiert. Dies ermöglicht die Entwicklung eines Projekts über Plattformen hinweg, die unterschiedliche Zeilenendstile verwenden, ohne dass Commits sehr laut sind, da jeder Editor den Zeilenendstil ändert, da der Zeilenendstil immer konsistent LF ist.

Der Nebeneffekt dieser praktischen Konvertierung, und darum geht es in der Warnung, die Sie sehen, besteht darin, dass eine Textdatei, die Sie ursprünglich erstellt haben, LF-Endungen anstelle von CRLF hatte, wie gewohnt mit LF gespeichert wird, aber wenn diese Option aktiviert ist später wird es CRLF-Endungen haben. Für normale Textdateien ist dies normalerweise in Ordnung. Die Warnung ist in diesem Fall ein "zu Ihrer Information", aber falls git eine Binärdatei fälschlicherweise als Textdatei bewertet, ist sie eine wichtige Warnung, da git dann Ihre Binärdatei beschädigen würde.

Wenn core.autocrlffalse festgelegt ist, wird niemals eine Konvertierung am Zeilenende durchgeführt, sodass Textdateien unverändert eingecheckt werden. Dies funktioniert normalerweise in Ordnung, solange alle Entwickler entweder unter Linux oder alle unter Windows arbeiten. Aber meiner Erfahrung nach bekomme ich immer noch Textdateien mit gemischten Zeilenenden, die Probleme verursachen.

Meine persönliche Präferenz ist es, die Einstellung als Windows-Entwickler aktiviert zu lassen.

Aktualisierte Informationen, die den Wert "input" enthalten, finden Sie unter http://kernel.org/pub/software/scm/git/docs/git-config.html .

Wenn Sie den Code bereits ausgecheckt haben, sind die Dateien bereits indiziert. Nachdem Sie Ihre Git-Einstellungen geändert haben, führen Sie beispielsweise Folgendes aus:

git config --global core.autocrlf input 

Sie sollten die Indizes mit aktualisieren

git rm --cached -r . 

und schreibe den Git-Index mit neu

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Hinweis: Dadurch werden Ihre lokalen Änderungen entfernt. Bevor Sie dies tun, sollten Sie sie verstauen.

git config core.autocrlf false

Sowohl unix2dos als auch dos2unix sind in Windows mit Gitbash verfügbar. Mit dem folgenden Befehl können Sie die Konvertierung von UNIX (LF) -> DOS (CRLF) durchführen. Daher erhalten Sie keine Warnung.

unix2dos filename

oder

dos2unix -D filename

Führen Sie diesen Befehl jedoch nicht für eine vorhandene CRLF-Datei aus, da sonst jede zweite Zeile leere Zeilenumbrüche angezeigt werden.

dos2unix -D filenamefunktioniert nicht mit jedem Betriebssystem. Bitte überprüfen Sie diesen Link auf Kompatibilität.

Wenn Sie den Befehl aus irgendeinem Grund erzwingen müssen, verwenden Sie --force. Wenn es ungültig heißt, verwenden Sie -f.

Ich denke, die Antwort von @ Basiloungas ist knapp, aber veraltet (zumindest auf dem Mac).

Öffnen Sie die Datei ~ / .gitconfig und setzen Sie sie safecrlfauf false

[core]
       autocrlf = input
       safecrlf = false

Das * wird es anscheinend dazu bringen, das Ende der Zeile char zu ignorieren (hat sowieso für mich funktioniert).

Der Artikel eines GitHub über Zeilenenden wird häufig erwähnt, wenn über dieses Thema gesprochen wird.

Meine persönlichen Erfahrungen mit der Verwendung der oft empfohlenen core.autocrlfKonfigurationseinstellung waren sehr gemischt.

Ich verwende Windows mit Cygwin und beschäftige mich zu unterschiedlichen Zeiten mit Windows- und UNIX-Projekten. Sogar meine Windows-Projekte verwenden manchmal bashShell-Skripte, für die UNIX-Zeilenenden (LF) erforderlich sind.

core.autocrlfWenn ich unter Verwendung der von GitHub empfohlenen Einstellung für Windows ein UNIX-Projekt auschecke (das unter Cygwin einwandfrei funktioniert - oder wenn ich zu einem Projekt beitrage, das ich auf meinem Linux-Server verwende), werden die Textdateien mit Windows (CRLF) ausgecheckt ) Zeilenenden, die Probleme verursachen.

Grundsätzlich core.autocrlffunktioniert es in einer gemischten Umgebung wie der in einigen Fällen nicht gut , die globale Einstellung auf eine der Optionen festzulegen. Diese Option kann in einer lokalen (Repository-) Git-Konfiguration festgelegt werden, aber selbst das wäre nicht gut genug für ein Projekt, das sowohl Windows- als auch UNIX-bezogene Inhalte enthält (z. B. habe ich ein Windows-Projekt mit einigen bashDienstprogramm-Skripten).

Die beste Wahl, die ich gefunden habe, ist das Erstellen von .gitattributes- Dateien pro Repository . Der GitHub-Artikel erwähnt es.
Beispiel aus diesem Artikel:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

In einem Repository meines Projekts:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

Es sind etwas mehr Dinge einzurichten, aber tun Sie es einmal pro Projekt, und jeder Mitwirkende unter jedem Betriebssystem sollte keine Probleme mit Zeilenenden haben, wenn er mit diesem Projekt arbeitet.

In vim öffnen Sie die Datei (zB: :e YOURFILEENTER), dann

:set noendofline binary
:wq

Ich hatte auch dieses Problem.

SVN führt keine Konvertierung von Zeilenenden durch, daher werden Dateien mit intakten CRLF-Zeilenenden festgeschrieben. Wenn Sie dann git-svn verwenden, um das Projekt in git zu platzieren, bleiben die CRLF-Endungen im git-Repository erhalten, in dem sich git nicht befindet. Standardmäßig werden nur Unix / Linux-Zeilenenden (LF) verwendet eingecheckt.

Wenn Sie dann die Dateien unter Windows auschecken, bleiben die Dateien bei der Autocrlf-Konvertierung intakt (da sie bereits die richtigen Endungen für die aktuelle Plattform haben). Der Prozess, der entscheidet, ob es einen Unterschied zu den eingecheckten Dateien gibt, führt jedoch die umgekehrte Konvertierung durch Vor dem Vergleich wird der LF in der ausgecheckten Datei mit einem unerwarteten CRLF im Repository verglichen.

Soweit ich sehen kann, haben Sie folgende Möglichkeiten:

1. Importieren Sie Ihren Code erneut in ein neues Git-Repository, ohne git-svn zu verwenden. Dies bedeutet, dass Zeilenenden im ersten git-Commit --all konvertiert werden
2. Setzen Sie autocrlf auf false und ignorieren Sie die Tatsache, dass die Zeilenenden nicht dem von git bevorzugten Stil entsprechen
3. Überprüfen Sie Ihre Dateien mit deaktiviertem Autocrlf, korrigieren Sie alle Zeilenenden, checken Sie alles wieder ein und schalten Sie es wieder ein.
4. Schreiben Sie den Verlauf Ihres Repositorys neu, sodass das ursprüngliche Commit nicht mehr die CRLF enthält, die Git nicht erwartet hat. (Es gelten die üblichen Einschränkungen beim Umschreiben der Historie.)

Fußnote: Wenn Sie Option 2 wählen, ist meine Erfahrung, dass einige der Zusatzwerkzeuge (Rebase, Patch usw.) nicht mit CRLF-Dateien umgehen und Sie früher oder später mit Dateien mit einer Mischung aus CRLF und LF (inkonsistente Zeile) enden Endungen). Ich kenne keine Möglichkeit, das Beste aus beiden herauszuholen.

Entfernen Sie das Folgende aus der Datei ~ / .gitattributes

* text=auto

verhindert, dass Git überhaupt die Zeilenenden überprüft.

Es sollte lauten:

Warnung: ( Wenn Sie es auschecken / oder in einen anderen Ordner klonen, in dem sich Ihre aktuelle Datei core.autocrlf befindet,true wird LF durch CRLF ersetzt

Die Datei hat ihre ursprünglichen Zeilenenden in Ihrem ( aktuellen ) Arbeitsverzeichnis.

Dieses Bild sollte erklären, was es bedeutet.

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Wenn Sie dies bei einem separaten Commit oder Git tun, werden möglicherweise immer noch ganze Dateien als geändert angezeigt, wenn Sie eine einzelne Änderung vornehmen (abhängig davon, ob Sie die Option autocrlf geändert haben).

Dieser funktioniert wirklich. Git respektiert die Zeilenenden in Projekten mit gemischten Zeilenenden und warnt Sie nicht davor.

Ich weiß nicht viel über Git unter Windows, aber ...

Mir scheint, dass git das Rückgabeformat so konvertiert, dass es dem der laufenden Plattform (Windows) entspricht. CRLF ist das Standardrückgabeformat in Windows, während LF das Standardrückgabeformat für die meisten anderen Betriebssysteme ist.

Möglicherweise wird das Rückgabeformat ordnungsgemäß angepasst, wenn der Code auf ein anderes System verschoben wird. Ich denke auch, dass Git klug genug ist, um Binärdateien intakt zu halten, anstatt zu versuchen, LFs in CRLFs in beispielsweise JPEGs zu konvertieren.

Zusammenfassend müssen Sie sich wahrscheinlich nicht zu sehr über diese Konvertierung ärgern. Wenn Sie jedoch Ihr Projekt als Tarball archivieren, würden andere Programmierer wahrscheinlich eher LF-Leitungsterminatoren als CRLF schätzen. Abhängig davon, wie sehr Sie sich interessieren (und davon, dass Sie Notepad nicht verwenden), möchten Sie möglicherweise git so einstellen, dass LF-Rückgaben verwendet werden, wenn Sie können :)

Anhang: CR ist ASCII-Code 13, LF ist ASCII-Code 10. Somit ist CRLF zwei Bytes, während LF eins ist.

Stellen Sie sicher, dass Sie das neueste Git installiert haben.
Ich habe wie oben beschrieben git config core.autocrlf false, als ich git (Version 2.7.1) verwendet habe, aber es hat nicht funktioniert.
Dann funktioniert es jetzt beim Upgrade von git (von 2.7.1 auf 2.20.1).

1. Öffnen Sie die Datei im Editor ++.
2. Gehen Sie zu Edit / EOL Conversion.
3. Klicken Sie auf das Windows-Format.
4. Speicher die Datei.

Die Frage von OP bezieht sich auf Windows und ich konnte keine anderen verwenden, ohne in das Verzeichnis zu gehen oder eine Datei in Notepad ++ auszuführen, da der Administrator nicht funktionierte. Also musste ich diesen Weg gehen:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

In vielen Texteditoren können Sie zu wechseln LF, siehe Atom-Anweisungen unten. Einfach und explizit.

Klicken Sie CRLFunten rechts auf:

Wählen LFSie oben in der Dropdown-Liste Folgendes aus:

In einer GNU / Linux-Shell-Eingabeaufforderung können Sie mit den Befehlen dos2unix & unix2dos Ihre von MS Windows stammenden Dateien einfach konvertieren / formatieren

CRLF kann Probleme verursachen, wenn Sie Ihren "Code" in zwei verschiedenen Betriebssystemen (Linux und Windows) verwenden. Mein Python-Skript wurde im Linux-Docker-Container geschrieben und dann mit Windows Git-Bash gepusht. Es gab mir die Warnung, dass LF durch CRLF ersetzt wird. Ich habe nicht viel darüber nachgedacht, aber als ich das Skript später startete, hieß es /usr/bin/env: 'python\r': No such file or directory. Nun, das ist eine \rVerzweigung für Sie. Windows verwendet "CR" - Wagenrücklauf - über '\ n' als neues Zeilenzeichen - \n\r. Das müssen Sie vielleicht berücksichtigen.

Die meisten Tools in Windows akzeptieren nur LF in Textdateien. Beispielsweise können Sie das Verhalten von Visual Studio in einer Datei mit dem Namen ".editorconfig" mit folgendem Beispielinhalt (Teil) steuern:

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Nur das ursprüngliche Windows-Notepad funktioniert nicht mit LF, aber es gibt einige einfachere einfache Editor-Tools!

Daher sollten Sie LF auch in Textdateien in Windows verwenden. Dies ist meine Nachricht, dringend empfohlen! Es gibt keinen Grund, CRLF in Windows zu verwenden!

(Dieselbe Diskussion verwendet \ in include-Pfade in C / ++, es ist Bullshit, verwenden Sie #include <pathTo / myheader.h> mit Schrägstrich!, Es ist der C / ++ - Standard und alle Microsoft-Compiler unterstützen ihn).

Daher ist die richtige Einstellung für Git

git config core.autocrlf false

Meine Botschaft: Vergessen Sie alte Denkprogramme wie dos2unix und unix2dos. Stellen Sie in Ihrem Team klar, dass LF unter Windows ordnungsgemäß verwendet werden kann.