git ersetzt LF durch CRLF

Question

Ich führe Git auf einem Windows XP-Rechner aus und verwende Bash. Ich habe mein Projekt aus SVN exportiert und dann ein leeres Repository geklont.

Dann habe ich den Export in das Verzeichnis bare repositories eingefügt und eine:

git add -A

Daraufhin erhielt ich eine Liste von Nachrichten:

LF wird durch CRLF ersetzt

Was sind die Auswirkungen dieser Umstellung? Es handelt sich um eine .NET-Lösung in Visual Studio.

Answer 1

A GitHub-Artikel über Zeilenenden wird häufig erwähnt, wenn es um dieses Thema geht.

Meine persönliche Erfahrung mit der Verwendung der oft empfohlenen core.autocrlf config Einstellung war sehr gemischt.

Ich verwende Windows mit Cygwin und habe sowohl mit Windows- als auch mit UNIX-Projekten zu verschiedenen Zeiten zu tun. Sogar meine Windows-Projekte verwenden manchmal bash Shell-Skripte, die UNIX-Zeilenenden (LF) benötigen.

Mit der von GitHub empfohlenen core.autocrlf Wenn ich ein UNIX-Projekt unter Windows auschecke (was unter Cygwin einwandfrei funktioniert - oder vielleicht trage ich zu einem Projekt bei, das ich auf meinem Linux-Server verwende), werden die Textdateien mit Windows-Zeilenenden (CRLF) ausgecheckt, was zu Problemen führt.

In einer gemischten Umgebung, wie ich sie habe, ist die Einstellung der globalen core.autocrlf zu einer der Optionen wird in einigen Fällen nicht gut funktionieren. Diese Option könnte in einer lokalen (Repository-) Git-Konfiguration gesetzt werden, aber selbst das wäre nicht gut genug für ein Projekt, das sowohl Windows- als auch UNIX-bezogene Dinge enthält (z.B. habe ich ein Windows-Projekt mit einigen bash Utility-Skripte).

Die beste Wahl, die ich gefunden habe, ist es, pro Repository zu erstellen .gitattributes Dateien. Die Website 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 der Repositorys 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 ist zwar etwas aufwändiger, aber wenn man es einmal pro Projekt macht, sollte jeder Mitarbeiter auf jedem Betriebssystem keine Probleme mit den Zeilenenden haben, wenn er mit diesem Projekt arbeitet.

Answer 2

Ich denke, @Basiloungas's Antwort ist nahe dran, aber veraltet (zumindest auf dem Mac).

Öffnen Sie die Datei ~/.gitconfig und setzen Sie safecrlf zu falsch

[core]
       autocrlf = input
       safecrlf = false

Dadurch wird das Zeilenende-Zeichen offenbar ignoriert (bei mir hat es jedenfalls funktioniert).

Answer 3

Öffnen Sie in vim die Datei (z.B.: :e YOURFILEENTER ), dann

:set noendofline binary
:wq

Answer 4

Ich hatte dieses Problem auch.

SVN nimmt keine Umwandlung der Zeilenenden vor, so dass die Dateien mit intakten CRLF-Zeilenenden übergeben werden. Wenn Sie dann git-svn verwenden, um das Projekt in Git zu übertragen, bleiben die CRLF-Endungen im Git-Repository erhalten, was nicht der Zustand ist, den Git erwartet - standardmäßig werden nur Unix/Linux-Zeilenenden (LF) eingecheckt.

Wenn Sie dann die Dateien unter Windows auschecken, lässt die automatische Konvertierung die Dateien intakt (da sie bereits die korrekten Endungen für die aktuelle Plattform haben), aber der Prozess, der entscheidet, ob es einen Unterschied zu den eingecheckten Dateien gibt, führt die umgekehrte Konvertierung durch avant zu vergleichen, was dazu führt, dass das, was es für ein LF in der ausgecheckten Datei hält, mit einem unerwarteten CRLF im Repository verglichen wird.

Soweit ich sehen kann, haben Sie die Wahl:

1. Importieren Sie Ihren Code erneut in ein neues Git-Repository, ohne git-svn zu verwenden; dies bedeutet, dass die Zeilenenden im ersten git commit --all
2. Setzen Sie autocrlf auf false, und ignorieren Sie die Tatsache, dass die Zeilenenden nicht dem von Git bevorzugten Stil entsprechen
3. Checken Sie Ihre Dateien bei ausgeschaltetem Autocrlf aus, korrigieren Sie alle Zeilenenden, checken Sie alles wieder ein, und schalten Sie es wieder ein.
4. Schreiben Sie die Historie Ihres Repositorys so um, dass der ursprüngliche Commit nicht mehr das CRLF enthält, das Git nicht erwartet hat. (Es gelten die üblichen Vorbehalte gegen das Umschreiben der Historie)

---

Fußnote: Wenn Sie sich für Option 2 entscheiden, dann ist meine Erfahrung, dass einige der Zusatzprogramme (Rebase, Patch usw.) nicht mit CRLF-Dateien zurechtkommen und Sie früher oder später mit Dateien mit einer Mischung aus CRLF und LF (inkonsistente Zeilenenden) enden. Ich weiß nicht, wie man das Beste aus beidem herausholen kann.

Answer 5

Die meisten Tools in Windows akzeptieren auch einen einfachen LF in Textdateien. Zum Beispiel können Sie das Verhalten für Visual Studio in einer Datei namens '.editorconfig' mit folgendem Beispielinhalt (Teil) steuern:

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

Lediglich das originale Windows-Notepad funktioniert nicht mit LF, aber es gibt ja auch noch ein paar ordentliche einfache Editor-Tools!

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

(Die gleiche Diskussion ist die Verwendung von \ in Include-Pfaden in C/++, es ist Blödsinn, verwenden Sie #include <pathTo/myheader.h> mit Schrägstrich, es ist der C/++ Standard und alle Microsoft-Compiler unterstützen es).

Die richtige Einstellung für git ist daher

git config core.autocrlf false

Meine Nachricht: Vergessen Sie solche alten Denkprogramme wie dos2unix und unix2dos. Klären Sie in Ihrem Team, dass LF unter Windows zu verwenden ist.