Git ersetzt LF durch CRLF

839

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.

mrblah
quelle
14
@apphacker, weil das Standardisieren von Zeilenenden weniger ärgerlich ist, als sie selbst zu ändern, wenn zwei Dateien unterschieden werden. (Und wenn Sie nicht einverstanden sind, können Sie die Funktion core.autocrlf natürlich deaktivieren.)
RJFalconer
2
Warum sollten die Zeilenenden anders sein, wenn nicht die gesamte Zeile berührt wurde
Björn
3
Ich berühre oft viele Zeilen, weil ich mit verschiedenen Ideen experimentiere, Trace-Anweisungen hinzufüge, um zu sehen, wie sie funktionieren usw. Dann möchte ich vielleicht nur zwei oder drei Zeilen ändern und git die anderen völlig ignorieren, weil ich hatte sie so zurückgelegt, wie ich sie gefunden hatte (oder so dachte ich).
MatrixFrog
5
@MatrixFrog: Ihr Editor scheint defekt zu sein und kann Zeilenenden nicht automatisch erkennen. Welches ist es? Ich arbeite an Hybridprojekten, die einige LF-Dateien und einige andere CRLF-Dateien im selben Repo haben müssen. Kein Problem für einen modernen Editor. Es ist die schlimmste Idee, Versionskontrolle (oder Dateiübertragung) mit Zeilenenden zu haben, um die Einschränkungen des Editors zu umgehen - offensichtlich aus der bloßen Länge der folgenden Erklärungen.
MarcH
4
Der einzige moderne Editor, den ich kenne, der das Falsche tut, ist Visual Studio. Visual Studio öffnet gerne eine Datei mit LF-Zeilenenden. Wenn Sie dann neue Zeilen einfügen, wird CRLF eingefügt und gemischte Zeilenenden werden gespeichert. Microsoft weigert sich, dies zu beheben, was ein ziemlich großer Fehler bei einer ansonsten ziemlich guten IDE ist: - (
Jon Watte

Antworten:

957

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.

Antony Hatchkins
quelle
28
Für die Zeit, die ich aufgewendet habe, um so weit zu kommen, habe ich auf einen core.crlf = Rackoff gehofft ;-)
PandaWood
10
Ich habe den Inhalt umstrukturiert, vielleicht ist es einfacher, ihn so zu lesen
Antony Hatchkins
7
Entschuldigung, ich hoffe, mein Kommentar wurde nicht als Kritik an Ihrer Antwort verstanden. Mit "so weit kommen" meine ich, bevor ich diese Antwort finde.
PandaWood
10
Das ist so verwirrend. Ich habe LF in meinem Editor eingestellt. Der gesamte Repo-Code verwendet LF. global autocrlf ist auf false gesetzt und die Kern-gitconfig in meinem Home-Verzeichnis ist auf false gesetzt. Aber ich bekomme immer noch die Nachricht, dass LF durch CRLF ersetzt wird
isimmons
17
Wenn Sie Ihren Editor für die Verwendung von Endungen im Unix-Stil konfiguriert haben, können Sie core.autocrlfdie Eingabe festlegen . Nach dem, was ich aus Ihrer Antwort entnommen habe, stellt das Setzen auf Eingabe sicher, dass das Repository und das Arbeitsverzeichnis immer Zeilenenden im Unix-Stil haben. Warum sollten Sie das unter Windows niemals wollen?
Hubro
764

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 .

Andrew Arnott
quelle
116
Wie hier gesagt ( stackoverflow.com/questions/1249932/… ), würde ich respektvoll widersprechen und diese Einstellung auf AUS setzen (und Notepad ++ oder einen anderen Editor verwenden, der in der Lage ist, mit jedem Endzeilenzeichen umzugehen - und es so zu lassen, wie es ist) es findet)
VonC
23
Ich mag diese Antwort und lasse autocrlf lieber auf true. Gibt es alternativ eine Möglichkeit, die Warnmeldungen automatisch zu beenden?
Krisc
12
Es wäre schön, diese gut geschriebene Antwort durch einen Vergleich mit den core.eolEinstellungen zu ergänzen , möglicherweise in Übereinstimmung mit der .gitattributesKonfiguration. Ich habe versucht, die Unterschiede und Überschneidungen durch Experimente herauszufinden, und es ist sehr verwirrend.
seh
5
Für eine dauerhaftere Lösung ändern Sie Ihre .gitconfig in: [core] autocrlf = false
RBZ
9
Gibt es eine einfache Möglichkeit, die Warnung einfach zu unterdrücken? Ich möchte, dass es wahr ist und weiß, dass ich es wahr gemacht habe. Ich muss nicht immer alle Warnungen sehen ... Es ist in Ordnung, wirklich ...: p
UmaN
160

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.

user2630328
quelle
23
Vielen Dank für eine einfache, plattformübergreifende und klare Möglichkeit, das Problem zu beheben, und nicht für eine ausführliche Diskussion über die Bedeutung der Konfiguration.
Eris
2
Wenn Git zurückgesetzt wird, ist es möglich, dass meine lokale Änderung verloren geht? Ich folge einfach allen Kommentaren oben
Freddy Sidauruk
5
Ja, Ihre lokalen Änderungen gehen verloren. Der Parameter --hard setzt den Index und den Arbeitsbaum zurück, sodass alle Änderungen an verfolgten Dateien verworfen werden. git-scm.com/docs/git-reset
Jacques
2
Was bedeutet das git rm --cached -r .? Warum git reset --hardist nicht genug?
Gavenkoa
2
@gavenkoa @max Sie benötigen das git rm --cached -r .Wenn Sie dies git reset --hardnach dem Ändern der core.autocrlfEinstellung tun , werden die Zeilenenden nicht erneut konvertiert. Sie müssen den Git-Index bereinigen.
wisbucky
80
git config core.autocrlf false
Arun
quelle
6
Stellen Sie sicher, dass Sie diese im Repository-Stamm ausführen
Hammad Khan
23
Ich verstehe nicht, wie das nützlich sein kann. Die Hälfte der Leute benötigt autocrlf, damit es funktioniert, die andere Hälfte muss falsch / eingegeben sein. Also, was, sollen sie diese einmaligen Antworten zufällig auf ihre Konsolenwand werfen, bis etwas klebt und irgendwie "funktioniert"? Das ist nicht produktiv.
Zoran Pavlovic
Ich erhalte die Fehlermeldung "Schwerwiegend: Nicht in einem Git-Verzeichnis". Ich habe versucht, zu C: \ Programme \ Git und C: \ Programme \ Git \ bin
pixelwiz
2
@mbb-Einstellung, autcrlfum falsedas Problem nur jedem Benutzer Ihres Projekts zuzuweisen .
Jpaugh
5
@pixelwiz: Dieser Befehl legt die Eigenschaft nur für das Projekt fest (Sie müssen sich also unter einem Git-Repository befinden, um es auszuführen). Wenn Sie dies global festlegen möchten, verwenden Sie git config --global core.autocrlf falsestattdessen.
Michaël Polla
49

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.

Rifat
quelle
8
Was tut es?
Salman von Abbas
1
In der Hilfeoption heißt es: `--u2d, -D UNIX durchführen -> DOS-Konvertierung`
Larry Battle
1
@ Rifat Ich bin verwirrt. Ihr Kommentar besagt, dass dos2unix -DWindows-Zeilenenden in Linux-Zeilenenden konvertiert werden. Ist das nicht dasselbe wie DOS (CRLF) -> UNIX (LF) Konvertierung? Gibt jedoch an dos2unix -h, dass -Deine UNIX (LF) -> DOS (CRLF) -Konvertierung durchgeführt wird. dos2unix Weitere Informationen: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix
Larry Battle
1
@ LarryBattle Ja, du hast Recht mit -D. Eigentlich habe ich die Antwort gepostet, als ich ein Windows-Benutzer war. Und ich habe den Kommentar mehr als ein Jahr später gemacht, als ich ein Mac-Benutzer bin: D Übrigens, danke für die Klarstellung.
Rifat
1
Das hat bei mir funktioniert. Ich verwende Cygwin, das den Schalter -D nicht zu unterstützen scheint - aber es gibt den Befehl "unix2dos", der dasselbe tut. Ich wünschte, ich wüsste, was das Problem verursacht hat - ich habe core.autocrlf = false und es ist ein reines Windows-Repository.
Richard Beier
28

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).

Jewgeni Simkin
quelle
1
Es sollte safecrlf(mit einem 'f') sein
Alpipego
22

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.

Gene Pavlovsky
quelle
Laufen Sie jetzt darauf und versuchen Sie, ein Repo mit Cygwin-Skripten unter anderen grundlegenden Textdateien zu verwalten. Wie würden Sie mit Dateien ohne Erweiterung umgehen (z. B. "fstab", "sshd_config")? Der verlinkte Artikel behandelt dieses Szenario nicht.
Mike Loux
1
@ MikeLoux Versuchen Sie diese Methode: stackoverflow.com/a/44806034/4377192
Gene Pavlovsky
Ich fand, dass das text=false eol=falseetwas ähnlich funktionierte binary. Klingt das richtig? Es könnte nützlich sein anzugeben "Ich weiß, dass dies Textdateien sind, aber ich möchte nicht, dass sie normalisiert werden"
joeytwiddle
19

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

:set noendofline binary
:wq
Roman Rhrn Nesterov
quelle
2
Durch einfaches Bearbeiten mit vimwürde das gesamte Zeilenende intakt bleiben.
Auge
Ich habe dieses Problem mit einigen Cocoapods-Dateien. Das Obige hat die meisten von ihnen behoben; im übrigen hat s / {control-v} {control-m} // den Trick gemacht. Die beiden Steuercodes zusammen ergeben das ^ M, das diejenigen von uns unter OS X häufig in Windows-Dateien sehen.
Janineanne
16

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.

Tim Abell
quelle
2
Ich denke, es gibt eine vierte Option, die Sie zu Ihrer Liste hinzufügen können, vorausgesetzt, Sie können es sich leisten, den Verlauf neu zu schreiben: Sie können ein Git-Repo, das Sie ursprünglich mit git-svn erstellt haben, neu schreiben und seinen Verlauf neu schreiben, um keine CRLF-Zeilenvorschübe mehr zu haben. Dies würde Ihnen normalisierte Zeilenvorschübe geben, die sich rückwärts durch Ihren gesamten SVN-Verlauf erstrecken. User keo präsentiert eine Lösung unter stackoverflow.com/a/1060828/64257 .
Chris
Über Ihre Fußnote: rebasehat kein Problem mit CRLF. Das einzige mir bekannte Problem ist, dass das Standard-Git-Merge-Tool seine Konfliktmarkierungen ("<<<<<<", ">>>>>>" usw.) nur mit LF einfügt, sodass eine Datei mit Konfliktmarkierungen verwendet wird gemischte Zeilenenden haben. Sobald Sie jedoch die Markierungen entfernt haben, ist alles in Ordnung.
Sleske
Es ist möglich, dass sich das Handling von git in den letzten 3 Jahren geändert hat. Dies war meine direkte Erfahrung damit. Ich musste dieses spezielle Problem seitdem nicht mehr wiederholen. ymmv.
Tim Abell
1
@sleske ab Git 2.8 führen die Merge-Marker kein gemischtes Zeilenende mehr ein. Siehe stackoverflow.com/a/35474954/6309
VonC
@VonC: Das ist cool. Gut zu wissen, wann ich unter Windows arbeiten muss.
Sleske
12

Entfernen Sie das Folgende aus der Datei ~ / .gitattributes

* text=auto

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

Basiloungas
quelle
6
Falsch. Diese Linie, falls vorhanden, überschreibt die Konfiguration von core.autocrlf. Wenn dies auf 'true' gesetzt ist, wird durch das Entfernen dieser Zeile nicht verhindert, dass git die Zeilenenden überprüft.
Arafangion
1
Wenn core.autocrlf auf gesetzt ist false, hilft es nicht viel, wenn autocrlf auf false gesetzt wird. Wenn dies nicht entfernt wird, hilft mir dies nicht (aber dies allein reicht nicht aus).
Matty
2
Upvoting das !! Während der Teil "Verhindert, dass Git überprüft wird" technisch nicht korrekt ist, ist dies die EINZIGE Antwort, in der die text=Einstellung .gitattributesüberhaupt ausdrücklich erwähnt wird (die, falls vorhanden, ein Blocker sein wird). Die anderen Antworten sind also unvollständig. Ich war verrückt, um herauszufinden, warum meine Dateien weiterhin als "geändert" angezeigt wurden, egal wie oft ich meine Einstellungen geändert autocrlfund safecrlfden Git-Cache ausgecheckt und gelöscht und den Hard-Reset durchgeführt habe.
JDunk
10

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. Geben Sie hier die Bildbeschreibung ein

Xiao Peng - ZenUML.com
quelle
Dies bedeutet auch, dass das, was an Subversion gesendet wird (wenn Sie dies tun), die Konvertierung hat.
Jpaugh
10

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.

Michael Ribbons
quelle
2
Dies ist besonders nützlich, wenn Sie zwischen CRLF und LF konvertieren möchten, aber einige .sh-Dateien haben, die intakt bleiben müssen. Ich benutze die *.sh -crlfganze Zeit ...
MartinTeeVarga
9

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.

Joey Adams
quelle
5
Da es niemand gesagt zu haben scheint, steht CR für "Carriage Return" und LF für "Line Feed". Als zweite Anmerkung ändern viele Windows-Editoren stillschweigend eine Textdatei, wobei das LF-Zeichen eine neue Zeile kennzeichnet, um stattdessen das Zeichenpaar CRLF zu sein. Der Benutzer des Editors wird nicht einmal gewarnt, aber Git wird die Änderung sehen.
user2548343
7

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).

Hyvi Tan
quelle
Ich denke du meintest du hättest git 2.17.1. Ich hatte das gleiche Problem und habe das Update durchgeführt, wodurch es auch behoben wurde. Ich bin froh, dass ich deine Antwort gesehen habe!
Phillip McMullen
5
  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.
1991tama1991
quelle
1
Versuchen Sie auch git config --global core.autocrlf false, Git daran zu hindern, die Zeilenenden Unixbei einem Commit auf zu setzen. Follow - up mit git config core.autocrlfihm zu überprüfen , in der Tat auf false gesetzt ist.
Contango
5

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
tiltedtimmy
quelle
3

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


Klicken Sie CRLFunten rechts auf:

Geben Sie hier die Bildbeschreibung ein

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

Geben Sie hier die Bildbeschreibung ein

JBallin
quelle
2

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

Ronan
quelle
2

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.

Kshitiz
quelle
0

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.

Hartmut Schorrig
quelle