2014-02-08 6 views
6

Mit Git unter Windows möchte ich sicherstellen, normalisierte Zeilenenden im Repository und keine Konvertierung in Arbeitsverzeichnis?Mit Git unter Windows, wie stelle ich sicher, normalisierte Zeilenenden im Repository und keine Konvertierung in Arbeitsverzeichnis?

Wir verwenden jetzt .gitattributes-Dateien mit * text=auto, um sicherzustellen, dass die Git-Repositories normalisiert sind. Wenn eine .gitattributes-Datei verwendet wird, werden alle Textdateien im Repository als LF gespeichert. Das ist gut. Das Problem ist, wenn sie in das Arbeitsverzeichnis geschrieben werden, ändert es die Zeilenendungen in core.eol, obwohl wir core.autocrlf=true nicht haben. Wenn .gitattributes verwendet wird, sollte es dasselbe Verhalten haben, wenn .gitattributes beim Schreiben in das Arbeitsverzeichnis nicht verwendet wird. Es sollte die Zeilenenden nur ändern, wenn core.autocrlf=true. Ich werde einen Fehler einreichen. Rot markiert ist Verhalten, von dem ich glaube, dass es geändert werden sollte.

enter image description here

In meinem Anwendungsfall, ich baue auf Build-Server, die beide Teamcity und Visual Studio Online, und nicht core.autocrlf=input einstellen. Ich werde den Open-Source-F # -Compiler als Beispiel verwenden. Das Projekt verwendet * text=auto und gibt *.fs text eol=lf in seiner .gitattributes nicht an. Wenn Sie il.fs aus dem GitHub-Repository herunterladen, sind die Zeilenenden LF. Wenn sie vom Build-Server ausgecheckt werden, handelt es sich um CRLF. Dies bedeutet, dass die Prüfsummen nicht übereinstimmen und die Quellindexierung mit SourceLink nicht funktioniert.

Als Workaround habe ich empfohlen, *.fs text eol=lf in der .gitattributes-Datei zu setzen. Nicht jeder ist damit glücklich.

Kann auch jemand mit 1500 Rufpunkten dies als "sourcelink" markieren.

+2

Haben Sie es nicht nur selbst beantworten? Verwenden Sie 'core.autocrlf = input', da' text = auto' nur verwendet werden soll, wenn 'core.autocrlf' nicht angegeben ist (gemäß https://help.github.com/articles/dealing-with-line-endings). –

+0

Zuerst hoffte ich auf ein anderes Verhalten, dann suchte ich nach einem '* text = input', fand aber keinen. Der Anwendungsfall ist, dass ich nicht die Möglichkeit habe, 'core.autocrlf = input' auf den Build-Servern zu setzen. Ich werde der Frage weitere Details zum Anwendungsfall hinzufügen. –

+0

Ich habe eine Feature-Anforderung [mysysgit/mysysgit # 164] (https://github.com/msysgit/msysgit/issues/164) eingereicht, um ** die Option "text = input" für gitattributes ** hinzuzufügen. –

Antwort

0

Aktualisieren Sie Ihre globalen Einstellungen über die Eingabeaufforderung

https://help.github.com/articles/dealing-with-line-endings

+0

In meinem Anwendungsfall möchte ich auf den Build-Servern aufbauen, auf denen ich die globalen Einstellungen nicht festlegen kann. Das Standardverhalten von Git sollte so aussehen, dass die Dateien des Arbeitsverzeichnisses mit dem Repository übereinstimmen. Das war das Verhalten bis vor kurzem. Ich habe darüber und mehr in einem Beitrag mit dem Titel "Zeit, um die Wagenrückgabe zu töten" gebloggt. http://blog.ctaggart.com/2014/02/time-to-kill-carriage-return.html –

Verwandte Themen