Warum sollte ich core.autocrlf=true in Git verwenden?

Question

Ich habe ein Git-Repository, das von sowohl Windows als auch OS X aus zugegriffen wird und das bereits einige Dateien mit CRLF-Zeilenumbrüchen enthält. Soweit ich das beurteilen kann, gibt es zwei Möglichkeiten, damit umzugehen:

1. Setze core.autocrlf überall auf false,

2. Befolge die Anweisungen hier (auf GitHub's Hilfeseiten wiederholt), um das Repository nur LF-Zeilenumbrüche enthalten zu lassen und setze danach core.autocrlf auf true auf Windows und input auf OS X. Das Problem dabei ist, dass falls ich binäre Dateien im Repository habe, die:

   1. nicht korrekt als binär in der gitattributes-Datei markiert sind, und
   2. sowohl CRLFs als auch LFs enthalten,

   sie beschädigt werden. Es ist möglich, dass mein Repository solche Dateien enthält.

Also warum sollte ich die Umwandlung der Zeilenumbrüche in Git nicht einfach ausschalten? Im Internet gibt es viele vage Warnungen darüber, dass das Ausschalten von core.autocrlf Probleme verursachen kann, aber sehr wenige spezifische; die einzigen, die ich bisher gefunden habe, sind, dass kdiff3 nicht mit CRLF-Zeilenumbrüchen umgehen kann (für mich kein Problem) und dass einige Texteditoren Probleme mit Zeilenumbrüchen haben (ebenfalls kein Problem für mich).

Das Repository ist intern in meinem Unternehmen, und daher muss ich mir keine Gedanken darüber machen, es mit Personen zu teilen, die unterschiedliche autocrlf-Einstellungen oder Zeilenumbruchanforderungen haben.

Gibt es irgendwelche anderen Probleme, wenn ich die Zeilenumbrüche so lasse, wie sie sind und nicht ändere, von denen ich nichts weiß?

Answer 1

Die einzigen spezifischen Gründe, autocrlf auf true zu setzen, sind:

• Vermeiden Sie, dass git status alle Ihre Dateien als modified anzeigt, weil die automatische EOL-Konvertierung erfolgt, wenn ein Unix-basiertes EOL Git-Repository auf ein Windows-basiertes EOL-Repository geklont wird (siehe Issue 83 zum Beispiel)
• und Ihre Codierungstools irgendwie von einem nativen EOL-Stil in Ihrer Datei abhängen:
  • zum Beispiel ein Codegenerator, der fest codiert ist, um native EOL zu erkennen
  • andere externe Batches (extern zum Repository) mit Regex oder Code, um native EOL zu erkennen
  • Ich glaube, einige Eclipse-Plugins können Dateien mit CRLF produzieren, unabhängig von der Plattform, was ein Problem darstellen kann.
  • Sie codieren mit Notepad.exe (es sei denn, Sie verwenden Windows 10 2018.09+, wo Notepad das erkannte EOL-Zeichen respektiert).

Sofern Sie keine spezifische Behandlung sehen können, die mit nativem EOL umgehen muss, ist es besser, autocrlf auf false zu lassen (git config --global core.autocrlf false).

Beachten Sie, dass diese Konfiguration eine lokale Konfiguration ist (weil die Konfiguration nicht von Repository zu Repository gepusht wird)

Wenn Sie dieselbe Konfiguration für alle Benutzer möchten, die dieses Repository klonen, schauen Sie sich "What's the best CRLF handling strategy with git?" an, unter Verwendung des text-Attributs in der .gitattributes-Datei.

Beispiel:

*.vcproj    text eol=crlf
*.sh        text eol=lf

---

Hinweis: Ab Git 2.8 (März 2016) führen Merge-Marker nicht mehr zu gemischten Zeilenenden (LF) in einer CRLF-Datei ein.
Siehe "Make Git use CRLF on its “<<<<<<< HEAD” merge lines"

Answer 2

Ich bin ein .NET-Entwickler und habe Git und Visual Studio seit Jahren verwendet. Meine klare Empfehlung ist, die Zeilenenden auf true zu setzen. Und tun Sie dies so früh wie möglich im Lebenszyklus Ihres Repositorys.

Das gesagt habend, HASSE ich es, dass Git meine Zeilenenden ändert. Die Versionskontrolle sollte nur die Arbeit speichern und abrufen, die ich mache, sie sollte sie NICHT ändern. Niemals. Aber das tut es.

Was passieren wird, wenn nicht jeder Entwickler auf true gesetzt ist, ist dass EIN Entwickler schließlich auf true setzen wird. Dies wird beginnen, die Zeilenenden aller Ihrer Dateien auf LF in Ihrem Repo zu ändern. Und wenn Benutzer mit false sie auschecken, wird Visual Studio Sie warnen und Sie auffordern, sie zu ändern. Es werden sehr schnell 2 Dinge passieren. Erstens, Sie werden immer mehr dieser Warnungen erhalten, je größer Ihr Team ist, desto mehr erhalten Sie. Das zweite, und noch schlimmere, ist dass angezeigt wird, dass jede Zeile jeder geänderten Datei geändert wurde (weil die Zeilenenden jeder Zeile vom true-Guy geändert werden). Letztendlich werden Sie Änderungen in Ihrem Repository nicht mehr zuverlässig verfolgen können. Es ist VIEL einfacher und sauberer, alle dazu zu bringen, bei true zu bleiben, als zu versuchen, alle bei false zu halten. So schrecklich es auch ist, mit der Tatsache zu leben, dass Ihre vertrauenswürdige Versionskontrolle etwas tut, was sie nicht tun sollte. Niemals.

Answer 3

Aktualisierung 2:

Xcode 9 scheint eine "Funktion" zu haben, bei der es die aktuellen Zeilenenden der Datei ignoriert und stattdessen einfach Ihre Standard-Zeilenenden-Einstellung verwendet, wenn es Zeilen in eine Datei einfügt, was zu Dateien mit gemischten Zeilenenden führt.

Ich bin ziemlich sicher, dass dieser Fehler in Xcode 7 nicht existierte; bezüglich Xcode 8 bin ich mir nicht sicher. Die gute Nachricht ist, dass es in Xcode 10 behoben zu sein scheint.

Während seiner Existenz hat dieser Fehler in dem Codebase, auf den ich in der Frage verweise (der bis heute autocrlf=false verwendet), für ein wenig Heiterkeit gesorgt und zu vielen "EOL"-Commit-Nachrichten geführt, und schließlich dazu, dass ich einen git-pre-commit-Hook geschrieben habe, um das Einführen gemischter Zeilenenden zu überprüfen/zu verhindern.

Aktualisierung:

Hinweis: Wie von VonC erwähnt, werden Merge-Marker ab Git 2.8 nicht Unix-artige Zeilenenden in eine Windows-artige Datei einführen.

Ursprünglich:

Ein kleines Problem, das ich bei diesem Setup bemerkt habe, ist, dass wenn es Merge-Konflikte gibt, die von git hinzugefügten Zeilen zur Kennzeichnung der Unterschiede nicht Windows-Zeilenumbrüche haben, selbst wenn der Rest der Datei das hat, und Sie am Ende eine Datei mit gemischten Zeilenumbrüchen haben, z.B.:

// Einige Codezeilen
<<<<<<< Aktualisierte Quelle
// Änderung A
=======
// Änderung B
>>>>>>> Zwischengespeicherte Änderungen
// Mehr Code

Dies verursacht bei uns keine Probleme (ich stelle mir vor, dass jedes Werkzeug, das beide Arten von Zeilenumbrüchen verarbeiten kann, auch vernünftig mit gemischten Zeilenumbrüchen umgeht - sicherlich tun es alle, die wir verwenden), aber es ist etwas, worüber man sich im Klaren sein sollte.

Das andere*, was wir herausgefunden haben, ist, dass bei der Verwendung von git diff zum Anzeigen von Änderungen an einer Datei mit Windows-Zeilenumbrüchen, hinzugefügte Zeilen ihre Wagenrückläufe anzeigen, also:

    // Nicht geändert

+   // Neue Zeile hinzugefügt in^M
+^M
    // Nicht geändert
    // Nicht geändert

_{* Es rechtfertigt nicht wirklich den Begriff: "Problem".}

Answer 4

Für mich.

Bearbeiten Sie die .gitattributes-Datei.

hinzufügen

*.dll binär

Dann läuft alles gut.

Answer 5

Ich arbeite auf GitHub und ich habe diesen Artikel hilfreich gefunden.

Es beschreibt die Konfiguration von git autocrlf und die Einstellung der .gitattributes-Datei.