Funktionsweise von Zeilenendkonvertierungen mit git core.autocrlf zwischen verschiedenen Betriebssystemen

Ich habe viele verschiedene Fragen und Antworten zum Stapelüberlauf sowie eine Git- Dokumentation zur Funktionsweise der Einstellung core.autocrlf gelesen .

Dies ist mein Verständnis von dem, was ich gelesen habe:

Unix- und Mac OSX-Clients (Pre-OSX verwendet CR) verwenden LF-Zeilenenden.
Windows-Clients verwenden CRLF-Zeilenenden.

Wenn core.autocrlf auf dem Client auf true gesetzt ist, speichert das Git-Repository Dateien immer im LF-Zeilenendenformat, und Zeilenenden in Dateien auf dem Client werden beim Auschecken / Festschreiben für Clients (dh Windows), die nicht verwenden, hin und her konvertiert -LF-Zeilenenden, unabhängig vom Format der Zeilenendendateien auf dem Client (dies stimmt nicht mit der Definition von Tim Clem überein - siehe Update unten).

Hier ist eine Matrix, die versucht, dasselbe für die Einstellungen 'input' und 'false' von core.autocrlf mit Fragezeichen zu dokumentieren, bei denen ich mir nicht sicher bin, ob das Konvertierungsverhalten am Zeilenende endet.

Meine Fragen sind:

1. Was sollen die Fragezeichen sein?
2. Ist diese Matrix für die "Nicht-Fragezeichen" korrekt?

Ich werde die Fragezeichen aus den Antworten aktualisieren, da sich ein Konsens zu bilden scheint.

                       core.autocrlf Wert
            true input false
-------------------------------------------------- --------
begehen | Konvertieren ? ?
neu | in LF (in LF konvertieren?) (keine Konvertierung?)

begehen | konvertieren zu ? Nein
vorhanden | LF-Konvertierung (in LF konvertieren?)

Kasse | konvertieren zu ? Nein
vorhanden | CRLF-Konvertierung (keine Konvertierung?)

Ich bin nicht wirklich auf der Suche nach Meinungen zu den Vor- und Nachteilen der verschiedenen Einstellungen. Ich suche nur nach Daten, die deutlich machen, wie zu erwarten ist, dass Git mit jeder der drei Einstellungen funktioniert.

- -

Update 17.04.2012 : Nachdem ich den Artikel von Tim Clem gelesen habe, der von JJD in den Kommentaren verlinkt wurde, habe ich einige der Werte in den "unbekannten" Werten in der obigen Tabelle geändert und "vorhandene Kasse | true" geändert, um sie zu konvertieren in CRLF anstatt in Client konvertieren ". Hier sind die Definitionen, die er gibt, die klarer sind als alles, was ich anderswo gesehen habe:

core.autocrlf = false

Dies ist die Standardeinstellung, aber die meisten Benutzer werden aufgefordert, dies sofort zu ändern. Das Ergebnis der Verwendung von false ist, dass Git niemals mit Zeilenenden in Ihrer Datei herumspielt. Sie können Dateien mit LF oder CRLF oder CR oder einer zufälligen Mischung dieser drei einchecken, und Git ist das egal. Dies kann das Lesen von Unterschieden erschweren und das Zusammenführen erschweren. Die meisten Leute, die in einer Unix / Linux-Welt arbeiten, verwenden diesen Wert, weil sie keine CRLF-Probleme haben und Git keine zusätzliche Arbeit benötigen, wenn Dateien in die Objektdatenbank geschrieben oder in das Arbeitsverzeichnis geschrieben werden.

core.autocrlf = true

Dies bedeutet, dass Git alle Textdateien verarbeitet und sicherstellt, dass CRLF beim Schreiben dieser Datei in die Objektdatenbank durch LF ersetzt wird, und dass alle LF beim Schreiben in das Arbeitsverzeichnis wieder in CRLF umgewandelt werden. Dies ist die empfohlene Einstellung unter Windows, da dadurch sichergestellt wird, dass Ihr Repository auf anderen Plattformen verwendet werden kann, während CRLF in Ihrem Arbeitsverzeichnis beibehalten wird.

core.autocrlf = Eingabe

Dies bedeutet, dass Git alle Textdateien verarbeitet und sicherstellt, dass CRLF durch LF ersetzt wird, wenn diese Datei in die Objektdatenbank geschrieben wird. Das Gegenteil ist jedoch nicht der Fall. Wenn Sie Dateien wieder aus der Objektdatenbank lesen und in das Arbeitsverzeichnis schreiben, haben sie immer noch LFs, um das Zeilenende zu kennzeichnen. Diese Einstellung wird im Allgemeinen unter Unix / Linux / OS X verwendet, um zu verhindern, dass CRLFs in das Repository geschrieben werden. Die Idee war, dass Git sicherstellen würde, wenn Sie Code aus einem Webbrowser einfügen und versehentlich CRLFs in eine Ihrer Dateien einfügen, dass diese beim Schreiben in die Objektdatenbank durch LFs ersetzt werden.

Tims Artikel ist ausgezeichnet. Ich kann mir nur vorstellen, dass das Repository im LF-Format vorliegt, was nicht unbedingt der Fall ist, insbesondere für Windows-Projekte.

Der Vergleich von Tims Artikel mit der bisher am höchsten bewerteten Antwort von jmlane zeigt eine perfekte Übereinstimmung hinsichtlich der wahren und Eingabeeinstellungen und Uneinigkeit hinsichtlich der falschen Einstellung.

Die beste Erklärung für die Funktionsweise core.autocrlffinden Sie auf der Manpage gitattributes im textAbschnitt Attribute.

So core.autocrlfscheint es derzeit zu funktionieren (oder zumindest seit Version 1.7.2, soweit mir bekannt ist):

• core.autocrlf = true
  1. Aus dem Repository ausgecheckte Textdateien, die nur LFZeichen enthalten, werden CRLFin Ihrem Arbeitsbaum normalisiert . Dateien, die CRLFim Repository enthalten sind, werden nicht berührt
  2. Textdateien, die nur LFZeichen im Repository enthalten, werden von CRLFbis normalisiert , LFwenn sie wieder in das Repository übernommen werden. Dateien, die CRLFim Repository enthalten sind, werden unberührt festgeschrieben.
• core.autocrlf = input
  1. Aus dem Repository ausgecheckte Textdateien behalten die ursprünglichen EOL-Zeichen in Ihrem Arbeitsbaum.
  2. Textdateien in Ihrem Arbeitsbaum mit CRLFZeichen werden normalisiert, LFwenn sie wieder in das Repository übernommen werden.
• core.autocrlf = false
  1. core.eol diktiert EOL-Zeichen in den Textdateien Ihres Arbeitsbaums.
  2. core.eol = nativeStandardmäßig bedeutet dies, dass sich Windows-EOLs CRLFund * nix-EOLs LFin Arbeitsbäumen befinden.
  3. Die Repository- gitattributesEinstellungen bestimmen die EOL-Zeichennormalisierung für Commits in das Repository (Standard ist die Normalisierung auf LFZeichen).

Ich habe dieses Problem erst kürzlich untersucht und finde die Situation auch sehr kompliziert. Die core.eolEinstellung hat definitiv dazu beigetragen, zu verdeutlichen, wie EOL-Zeichen von git behandelt werden.

Das Problem der EOLs in Projekten mit gemischten Plattformen hat mein Leben lange Zeit miserabel gemacht. Die Probleme in der Regel entstehen , wenn es bereits Dateien mit unterschiedlichen und gemischten EOLs bereits im Repo. Dies bedeutet, dass:

1. Das Repo kann unterschiedliche Dateien mit unterschiedlichen EOLs haben
2. Einige Dateien im Repo haben möglicherweise gemischte EOL, z. B. eine Kombination aus CRLFund LFin derselben Datei.

Wie dies geschieht, ist hier nicht das Problem, aber es passiert.

Ich habe unter Windows einige Konvertierungstests für die verschiedenen Modi und deren Kombinationen durchgeführt.
Folgendes habe ich in einer leicht modifizierten Tabelle erhalten:

                 | Resultierende Konvertierung, wenn | Resultierende Konvertierung wenn
                 | Festschreiben von Dateien mit verschiedenen | Auschecken von Repo -
                 | EOLs IN Repo und | mit gemischten Dateien und
                 | core.autocrlf Wert: | core.autocrlf Wert:           
-------------------------------------------------- ------------------------------
Datei | wahr | Eingabe | false | wahr | Eingabe | falsch
-------------------------------------------------- ------------------------------
Windows-CRLF | CRLF -> LF | CRLF -> LF | wie sie sind | wie sie sind | wie sie sind | wie es ist
Unix -LF | wie sie sind | wie sie sind | wie sie sind | LF -> CRLF | wie sie sind | wie es ist
Mac -CR | wie sie sind | wie sie sind | wie sie ist | wie sie ist | wie sie ist | wie es ist
Mixed-CRLF + LF | wie sie ist | wie sie sind | wie sie ist | wie sie ist | wie sie ist | wie es ist
Mixed-CRLF + LF + CR | wie sie ist | wie sie sind | wie sie sind | wie sie sind | wie sie sind | wie es ist

Wie Sie sehen, gibt es zwei Fälle, in denen die Konvertierung beim Festschreiben erfolgt (3 linke Spalten). In den übrigen Fällen werden die Dateien unverändert festgeschrieben.

Beim Auschecken (3 rechte Spalten) gibt es nur einen Fall, in dem die Konvertierung erfolgt, wenn:

1. core.autocrlfist true und
2. Die Datei im Repo hat die LFEOL.

Am überraschendsten für mich, und ich vermute, die Ursache für viele EOL-Probleme ist, dass es keine Konfiguration gibt, in der gemischte EOL wie CRLF+ LFnormalisiert werden.

Beachten Sie auch, dass "alte" Mac EOLs von CRnur auch nie konvertiert werden.
Dies bedeutet, dass wenn ein schlecht geschriebenes EOL-Konvertierungsskript versucht, eine gemischte Enddatei mit CRLFs + LFs zu konvertieren , indem nur LFs in CRLFs konvertiert wird, die Datei in einem gemischten Modus mit "einsamen" CRs belassen wird, wo immer a CRLFkonvertiert wurde CRCRLF.
Git konvertiert dann auch im trueModus nichts und EOL-Chaos geht weiter. Dies ist mir tatsächlich passiert und hat meine Dateien sehr durcheinander gebracht, da einige Editoren und Compiler (z. B. VS2010) Mac EOLs nicht mögen.

Ich denke, die einzige Möglichkeit, diese Probleme wirklich zu lösen, besteht darin, gelegentlich das gesamte Repo zu normalisieren, indem alle Dateien im inputoder im falseModus ausgecheckt, eine ordnungsgemäße Normalisierung ausgeführt und die geänderten Dateien (falls vorhanden) erneut festgeschrieben werden. Nehmen Sie unter Windows vermutlich die Arbeit wieder auf core.autocrlf true.

Mit dem kommenden Git 1.7.2 werden sich die Dinge im Bereich "EOL Conversion" ändern :

Eine neue Konfigurationseinstellung core.eolwird hinzugefügt / weiterentwickelt :

Dies ist ein Ersatz für das core.eolCommit 'Add " " config variable', das sich derzeit befindet pu(das letzte in meiner Serie).
Anstatt zu implizieren, dass " core.autocrlf=true" ein Ersatz für " * text=auto" ist, wird ausdrücklich darauf autocrlfhingewiesen , dass dies nur für Benutzer gilt, die mit CRLFs in ihrem Arbeitsverzeichnis in einem Repository ohne Normalisierung von Textdateien arbeiten möchten .
Wenn es aktiviert ist, wird "core.eol" ignoriert.

Führen Sie die neue Konfigurationsvariable " core.eol" ein, mit der der Benutzer festlegen kann, welche Zeilenenden für normalisierte Dateien am Zeilenende im Arbeitsverzeichnis verwendet werden sollen.
Der Standardwert ist " native", was CRLF unter Windows und LF überall sonst bedeutet. Beachten Sie, dass " core.autocrlf" überschreibt core.eol.
Dies bedeutet, dass:

[core]
  autocrlf = true

Setzt CRLFs in das Arbeitsverzeichnis, auch wenn core.eol" lf" eingestellt ist.

core.eol:

Legt den Zeilenende-Typ fest, der im Arbeitsverzeichnis für Dateien verwendet werden soll, für die die textEigenschaft festgelegt wurde.
Alternativen sind 'lf', 'crlf' und 'native', die das native Zeilenende der Plattform verwenden.
Der Standardwert ist native.

Andere Entwicklungen werden in Betracht gezogen :

Für 1.8 würde ich in Betracht ziehen, core.autocrlfeinfach die Normalisierung einzuschalten und die Entscheidung zum Beenden der Arbeitsverzeichniszeile bei core.eol zu belassen, aber das wird die Einstellungen der Leute beschädigen.

Git 2.8 (März 2016) verbessert die Art und Weise, wie core.autocrlfdas EOL beeinflusst wird:

Siehe commit 817a0c7 (23 Feb 2016), commit 6e336a5 , commit df747b8 , commit df747b8 (10 Feb 2016), commit df747b8 , commit df747b8 (10 Feb 2016) und commit 4b4024f , commit bb211b4 , commit 92cce13 , commit 320d39c , commit 4b4024f , Commit bb211b4 , Commit 92cce13 , Commit 320d39c (05. Februar 2016) von Torsten Bögershausen ( tboegi) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit c6b94eb, 26. Februar 2016)}

convert.c: Refaktor crlf_action

Refactor die Bestimmung und Verwendung von crlf_action.
Wenn heute kein " crlf" -Attribut für eine Datei festgelegt ist, crlf_actionwird auf gesetzt CRLF_GUESS. Verwenden Sie CRLF_UNDEFINEDstattdessen und suchen Sie wie zuvor nach " text" oder " eol".

Ersetzen Sie die alte CRLF_GUESSVerwendung:

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Machen Sie klarer, was was ist, indem Sie Folgendes definieren:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

Wie Torek in den Kommentaren hinzufügt :

Alle diese Übersetzungen (jede EOL-Konvertierung von eol=oder autocrlfEinstellungen und " clean" Filter) werden ausgeführt, wenn Dateien vom Arbeitsbaum zum Index verschoben werden , dh während git addund nicht zur git commitZeit.
(Beachten Sie jedoch, dass git commit -aoder --onlyoder --includefügen Sie zu diesem Zeitpunkt Dateien zum Index hinzu.)

Weitere Informationen hierzu finden Sie unter " Was ist der Unterschied zwischen autocrlf und eol? ".

core.autocrlfDer Wert hängt nicht vom Betriebssystemtyp ab, sondern vom Windows-Standardwert trueund für Linux - input. Ich habe 3 mögliche Werte für Commit- und Checkout-Fälle untersucht und dies ist die resultierende Tabelle:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Hier ist mein bisheriges Verständnis für den Fall, dass es jemandem hilft.

core.autocrlf=true und core.safecrlf = true

Sie haben ein Repository, in dem alle Zeilenenden gleich sind , aber Sie arbeiten auf verschiedenen Plattformen. Git stellt sicher, dass Ihre Zeilenenden in den Standard für Ihre Plattform konvertiert werden. Warum ist das wichtig? Angenommen, Sie erstellen eine neue Datei. Der Texteditor auf Ihrer Plattform verwendet die Standardzeilenenden. Wenn Sie beim Einchecken nicht "core.autocrlf" auf "true" gesetzt haben, haben Sie eine Inkonsistenz für das Zeilenende für jemanden auf einer Plattform eingeführt, die standardmäßig ein anderes Zeilenende verwendet. Ich habe immer auch safecrlf eingestellt, weil ich wissen möchte, dass die crlf-Operation reversibel ist. Mit diesen beiden Einstellungen ändert git Ihre Dateien, überprüft jedoch, ob die Änderungen umkehrbar sind .

core.autocrlf=false

Sie haben ein Repository, in dem bereits gemischte Zeilenenden eingecheckt sind, und das Korrigieren der falschen Zeilenenden kann andere Probleme verursachen. In diesem Fall ist es am besten, git nicht anzuweisen, Zeilenenden zu konvertieren, da dies das Problem, für das es entwickelt wurde, verschärft. Dadurch werden Unterschiede leichter lesbar und Zusammenführungen weniger schmerzhaft. Mit dieser Einstellung ändert git Ihre Dateien nicht .

core.autocrlf=input

Ich verwende dies nicht, da der Grund dafür darin besteht, einen Anwendungsfall abzudecken, in dem Sie eine Datei mit CRLF-Zeilenenden auf einer Plattform erstellt haben, die standardmäßig LF-Zeilenenden enthält. Ich bevorzuge stattdessen, dass mein Texteditor immer neue Dateien mit den Standardeinstellungen für das Zeilenende der Plattform speichert.

Nein, die @ jmlane-Antwort ist falsch.

Für Checkin (git add, git commit):

1. Wenn die textEigenschaft Set, Set value to 'auto'aktiviert ist , erfolgt die Konvertierung, wenn die Datei mit 'CRLF' festgeschrieben wurde.
2. Wenn textEigentum ist Unset: nichts passiert, enen fürCheckout
3. Wenn textEigenschaft ist Unspecified, hängt die Konvertierung von abcore.autocrlf
   1. Wenn autocrlf = input or autocrlf = truedie Konvertierung nur erfolgt, wenn die Datei im Repository 'LF' ist. Wenn es sich um 'CRLF' handelt, geschieht nichts.
   2. wenn autocrlf = falsenichts passiert

Für Checkout:

1. Wenn textEigentum ist Unset: nichts passiert.
2. Wenn textEigentum ist Set, Set value to 'auto: es hängt ab von core.autocrlf, core.eol.
   1. core.autocrlf = Eingabe: Es passiert nichts
   2. core.autocrlf = true: Die Konvertierung erfolgt nur, wenn die Datei im Repository 'LF', 'LF' -> 'CRLF' lautet.
   3. core.autocrlf = false: Die Konvertierung erfolgt nur, wenn die Datei im Repository 'LF', 'LF' -> lautet core.eol
3. Wenn textEigentum ist Unspecified, kommt es darauf an core.autocrlf.
   1. das Gleiche wie 2.1
   2. das Gleiche wie 2.2
   3. Keine, nichts passiert, core.eol ist nicht effektiv, wenn textEigentum istUnspecified

Standardverhalten

Das Standardverhalten ist also textEigenschaft ist Unspecifiedund core.autocrlf = false:

1. Beim Einchecken passiert nichts
2. Beim Auschecken passiert nichts

Schlussfolgerungen

1. wenn text Eigenschaft festgelegt ist, hängt das Eincheckverhalten von sich selbst und nicht von autocrlf ab
2. autocrlf oder core.eol steht für das Checkout-Verhalten und autocrlf> core.eol

Habe einige Tests sowohl unter Linux als auch unter Windows durchgeführt. Ich verwende eine Testdatei mit Zeilen, die auf LF enden, und Zeilen, die auf CRLF enden.
Die Datei wird festgeschrieben, entfernt und dann ausgecheckt. Der Wert von core.autocrlf wird vor dem Festschreiben und auch vor dem Auschecken festgelegt. Das Ergebnis ist unten.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF