Was ist die beste CRLF (Carriage Return, Zeilenvorschub) Behandlung Strategie mit Git?

StackOverflow https://stackoverflow.com/questions/170961

Frage

Ich habe versucht zu begehen Dateien mit CRLF endende Linien, aber es ist fehlgeschlagen.

verbrachte ich einen ganzen Arbeitstag auf meinem Windows-Computer verschiedene Strategien versucht, und war fast zu stoppen gezogen versucht Git zu verwenden und stattdessen versuchen, Mercurial .

Bitte teilen nur eine Best Practice pro Antwort.

War es hilfreich?

Lösung

Fast vier Jahre nach dieser Frage habe ich endlich gefunden eine Antwort, die mich vollständig erfüllt

Sehen Sie die Details in Github: help 's Guide zu Umgang mit Zeilenenden .

  

Git können Sie die Zeilenende Eigenschaften für ein setzen   Repo direkt die Textattribut in der Verwendung    .gitattributes Datei. Diese Datei hat sich verpflichtet, in   die Repo- und überschreiben die core.autocrlf Einstellung,   so dass Sie ein konsistentes Verhalten für alle zu gewährleisten   Benutzer unabhängig von ihren git Einstellungen.

So

  

Der Vorteil hierbei ist, dass Ihr Ende der Leitung   Konfiguration bewegt sich nun mit Ihrem Repository und Sie   brauchen nicht darüber, ob oder nicht Mitarbeiter kümmern   haben die richtigen globalen Einstellungen.

Hier ist ein Beispiel für eine .gitattributes Datei 

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Es ist eine bequeme Sammlung von ready-Dateien für die beliebtesten Programmiersprachen verwenden .gitattributes. Es ist nützlich, um Ihnen den Einstieg.

Sobald Sie erstellt oder angepasst .gitattributes , sollten Sie eine durchführen einmal und für alles Zeilenende wieder Normalisierung .

Beachten Sie, dass die GitHub Desktop- App kann eine .gitattributes Datei vorschlagen und schaffen, nachdem Sie Git Ihr Projekt öffnen Repo in der App. Um zu versuchen, dass, klicken Sie auf das Zahnrad-Symbol (in der rechten oberen Ecke)> Repository-Einstellungen ...> Zeilenende und Attribute. Sie werden gefragt, die empfohlene hinzuzufügen .gitattributes und wenn Sie einverstanden sind, wird die App auch eine Normalisierung aller Dateien im Repository durchführen.

Schließlich Mind the das Ende der Linie Artikel mehr Hintergrund stellt und erklärt, wie Git entwickelt hat Bezug auf die bei der Hand. Ich halte dies für Pflichtlektüre .

Sie haben wahrscheinlich Benutzer in Ihrem Team, die EGit oder JGit verwenden (Tools wie Eclipse und Teamcity sie verwenden), um ihre Änderungen zu übernehmen. Dann bist du kein Glück, als @gatinueta in dieser Antwort Äußerungen erklärt:

  

Mit dieser Einstellung werden Sie nicht vollständig erfüllen, wenn man die Leute mit Egit oder JGit in Ihrem Team zu arbeiten hat, da diese Werkzeuge nur .gitattributes ignorieren und glücklich in CRLF Dateien überprüfen https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

Ein Trick könnte sein, um sie in einem anderen Mandanten ihre Änderungen haben zu begehen, sagen wir SourceTree . Unser Team zurück bevorzugt dann, dass Werkzeug EGit für viele Anwendungsfälle des Eclipse.

Wer hat gesagt, Software einfach ist? : - /

Andere Tipps

Sie Zeilenende nicht konvertieren. Es ist nicht die Aufgabe des VCS Daten zu interpretieren - nur speichern und Version davon. Jeder moderne Texteditor sowieso beide Arten von Zeilenenden lesen kann.

Sie wollen fast immer autocrlf=input wenn Sie wirklich wissen, was Sie tun.

Einige zusätzliche Kontext unter:

  

Es sollte entweder core.autocrlf=true sein, wenn Sie   DOS endet oder core.autocrlf=input wenn Sie es vorziehen   Unix-Zeilenumbrüche. In beiden Fällen wird Ihre Git-Repository   nur LF haben, was das Richtige ist. Das einzige   Argument für core.autocrlf=false war, dass die automatische   Heuristik falsch einige binäre als Text erfassen   und dann wird Ihre Fliese beschädigt. Damit,   core.safecrlf Option wurde eingeführt, um einen Benutzer zu warnen, wenn   eine unumkehrbare Änderung geschieht. In der Tat gibt es zwei   Möglichkeiten der irreversable Veränderungen - gemischt   Zeilenende in Textdatei, in dieser Normierung ist   wünschenswert, so kann diese Warnung ignoriert werden, oder   (Sehr unwahrscheinlich), die falsch erkannt Git Ihre   Binär-Datei als Text. Dann müssen Sie Attribute verwenden, um   sagen Git, dass diese Datei binär ist.

Der obige Absatz wurde ursprünglich von einem Thread auf gmane.org gezogen, aber es nach unten, da gegangen ist.

Zwei alternative Strategien zu erhalten konsistent über Zeilenenden in gemischten Umgebungen (Microsoft + Linux + Mac):

A. Globale pro Alle Repositorys Setup-

1) Convert alle zu einem Format 

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Stellen Sie core.autocrlf auf Linux / UNIX oder input auf MS Windows (Repository oder global)

true 
git config --global core.autocrlf input

3) [Optional] Satz core.safecrlf true (zu stoppen) oder warn (zu singen :) zusätzliche Wachen hinzufügen zu vergleichen, wenn die umgekehrte Newline Transformation in der gleichen Datei führen würde 

git config --global core.safecrlf true


B. Oder pro Repository-Setup

1) Convert alle zu einem Format 

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) in .gitattributes Datei auf Ihr Repository 

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Sie nicht über Ihre Binärdateien Sorge -. Git intelligent genug, um über sie sein sollte

Mehr über safecrlf / autocrlf Variablen

Versuchen Sie, die core.autocrlf Konfigurationsoption Einstellung true. Haben Sie auch einen Blick auf die core.safecrlf Option.

Eigentlich klingt es wie core.safecrlf vielleicht schon in Ihrem Repository, weil (Hervorhebung von mir) eingestellt werden:

  

Wenn dies nicht der Fall für die aktuelle Einstellung von core.autocrlf ist, git wird die Datei ablehnen .

Wenn dies der Fall ist, dann sollten Sie überprüfen, ob Ihr Text-Editor konfiguriert ist konsequent Zeilenende zu verwenden. Sie werden wahrscheinlich auf Probleme stoßen, wenn eine Textdatei, die eine Mischung von LF und CRLF Zeilenenden enthält.

Schließlich habe ich das Gefühl, dass die Empfehlung einfach „verwenden, was Sie gegeben“ und verwenden LF Linien auf Windows beendet wird mehr Probleme verursachen als sie löst. Git hat die oben genannten Optionen zu versuchen, Zeilenende in einer vernünftigen Art und Weise zu handhaben, so macht es Sinn, sie zu nutzen.

Mit core.autocrlf=false aus alle Dateien gestoppt, sobald aktualisiert markiert wird, wie ich sie in meinem Visuelle ausgecheckt Studio 2010 Projekt. Die beiden anderen Mitglieder des Entwicklungsteams sind auch mit Windows-Systemen so eine gemischte Umgebung nicht ins Spiel gekommen, aber die Standardeinstellungen, die mit dem Repository kam immer markiert alle Dateien als unmittelbar nach dem Klonen aktualisiert.

Ich denke, in der unteren Zeile zu finden ist, was CRLF Einstellung für Ihre Umgebung. Vor allem, da in vielen anderen Repositories auf unseren Linux-Boxen Einstellung autocrlf = true bessere Ergebnisse liefert.

20 Jahre später, und wir sind nach wie vor mit der Linie zu tun Unterschiede zwischen OSes Ende ... traurig.

Dies sind die beiden Optionen für Fenster und Visual Studio Benutzer diesen Anteil Code mit Mac oder Linux Benutzer . Für eine längere Erklärung, lesen Sie die gitattributes Handbuch .

* text = auto

In Ihrem Repo .gitattributes-Datei hinzu: 

*   text=auto

Damit werden alle Dateien mit LF Zeilenenden im Repo normalisieren.

Und je nach Betriebssystem (core.eol Einstellung), Dateien im Arbeits Baum normalisiert werden für Unix-basierte Systeme oder LF für Windows-Systeme CRLF.

Dies ist die Konfiguration, die Microsoft .NET repos Verwendung.

Beispiel: 

Hello\r\nWorld

Wird in der Repo normalisiert werden immer als: 

Hello\nWorld

Beim Auschecken wird die Arbeitsstruktur im Windows konvertiert werden: 

Hello\r\nWorld

Beim Auschecken wird der Arbeits Baum in Mac gelassen werden, wie: 

Hello\nWorld
  

Hinweis: Wenn Ihr Repo bereits Dateien nicht normalisiert enthält, wird git status diese Dateien zeigen, wie vollständig das nächste Mal, wenn Sie sie jede mögliche Änderung vornehmen geändert, und es könnte ein Schmerz für andere Benutzer zu später ihre Änderungen zusammenführen. Siehe erfrischend ein Repository nach Endungen Linie , um weitere Informationen zu ändern.

core.autocrlf = true

Wenn text ist nicht spezifiziert in der .gitattributes Datei, Git verwendet den core.autocrlf Konfigurationsvariable, um zu bestimmen, ob die Datei konvertiert werden soll.

Für Windows-Benutzer, git config --global core.autocrlf true ist eine gute Option, weil:

  • Dateien sind normalisierte Zeilenende LF nur, wenn hinzugefügt zu dem Repo. Wenn Dateien nicht normalisiert im Repo sind, wird diese Einstellung sie nicht berühren.
  • werden alle Textdateien CRLF Zeilenende im Arbeitsverzeichnis umgewandelt.

Das Problem bei diesem Ansatz ist, dass:

  • Wenn Sie ein Windows-Benutzer mit autocrlf = input sind, werden Sie eine Reihe von Dateien mit LF Zeilenenden sehen. Nicht eine Gefahr für den Rest des Teams, weil Ihre Commits noch mit LF Zeilenenden normalisiert werden.
  • Wenn Sie ein Windows-Benutzer mit core.autocrlf = false sind, werden Sie eine Reihe von Dateien mit LF Zeilenenden sehen und Sie können Dateien mit CRLF Zeilenenden in die Repo einführen.
  • Die meisten Mac-Anwender verwenden autocrlf = input und kann Dateien mit CRLF Dateiendungen, die wahrscheinlich von Windows-Benutzern mit core.autocrlf = false erhalten.

Dies ist nur eine Abhilfe Lösung:

Im Normalfall verwendet die Lösungen, die mit git versandt werden. Diese arbeiten sehr in den meisten Fällen. Force LF, wenn Sie die Entwicklung unter Windows und Unix-basierten Systemen gemeinsam nutzen, indem Sie .gitattributes .

In meinem Fall gab es> 10 Programmierer ein Projekt in Windows zu entwickeln. Dieses Projekt wurde geprüft mit CRLF und gibt es keine Möglichkeit, LF zu erzwingen.

Einige Einstellungen wurden intern geschrieben auf meinem Rechner ohne Einfluss auf das LF-Format; so wurden einige Dateien global verändert auf jeder kleinen Dateiänderung LF.

Meine Lösung:

Windows-Maschinen: Lassen Sie alles, wie es ist. Die Sorge um nichts, da Sie ein Standard-Windows ‚Eigenbrötler‘ Entwickler sind und Sie haben so zu handhaben: „Es gibt kein anderes System in der weiten Welt, ist es“

Unix-Maschinen

  1. Fügen Sie folgende Zeilen in einem [alias] Abschnitt config. Dieser Befehl listet alle geändert (d geändert / neu) Dateien: 

    lc = "!f() { git status --porcelain \
             | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
             | cut -c 4- ; }; f "

  2. Konvertieren alle, die geändert Dateien in DOS-Format: 

    unix2dos $(git lc)

  3. Optional ...

    1. Erstellen Sie eine git für diese Haken Aktion diesen Prozess zu automatisieren

    2. Mit params und schließen Sie sie und die grep Funktion ändern, dass nur bestimmte Dateinamen übereinstimmen, z.B .: 

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

    3. Fühlen Sie sich frei, um es noch einfacher zu machen, indem eine zusätzliche Verknüpfung mit: 

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... und feuern die konvertierte Sachen, indem Sie 

      git c2dos

Ich habe Stunden damit verbracht, mit der bestmöglichen Nutzung von .gitattributes zu kommen, um endlich zu erkennen, dass ich nicht auf sie zählen kann.
Leider solange JGit-basierte Editoren existieren (was nicht .gitattributes korrekt verarbeiten kann), ist die sichere Lösung LF zu zwingen, überall sogar auf Editor-Ebene.

Verwenden Sie die folgenden anti-CRLF Desinfektionsmittel.

--- UPDATE 2 ---

Die dafaults von git-Client wird in den meisten Fällen funktionieren. Selbst wenn Sie nur die Fenster nur Clients, Linux nur Kunden oder beides. Diese sind:

  • Fenster. core.autocrlf=true bedeutet Linien zu CRLF auf Kasse umwandeln und konvertieren Linien LF, wenn das Hinzufügen von Dateien
  • Linux:. core.autocrlf=input Mittel nicht Linien auf Kasse konvertieren (keine Notwendigkeit, da Dateien erwartet werden, mit LF begangen werden) und konvertieren Linien LF (falls erforderlich), wenn das Hinzufügen von Dateien

Die Eigenschaft kann in verschiedenen Bereichen eingestellt werden. Ich würde ausdrücklich vorschlagen im --global Umfang einstellen, einige IDE Probleme am Ende beschrieben zu vermeiden. 

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Auch würde ich dringend entmutigen mit git config --global core.autocrlf false (falls Sie nur Windows-Clients) im Gegensatz zu dem, was vorgeschlagen wird, git Dokumentation . Festlegen auf false werden die Dateien mit CRLF im Repo begehen. Aber es gibt wirklich keinen Grund. Man kann nie wissen, ob Sie das Projekt mit Linux-Benutzern teilen müssen. Außerdem ist es ein zusätzlicher Schritt für jeden Client, der das Projekt anstelle der Verwendung von Standardeinstellung verbindet.

Jetzt für einige spezielle Fälle von Dateien (z *.bat *.sh), die Sie wollen, dass sie mit LF oder CRLF abgemeldeten werden können Sie mit .gitattributes

Um es zusammenzufassen-up für mich, die best practice ist:

  • Stellen Sie sicher, dass jede nicht-Binärdatei mit LF auf git Repo (Standardverhalten) verpflichtet.
  • Verwenden Sie diesen Befehl, um sicherzustellen, dass keine Dateien mit CRLF begangen werden: git grep -I --files-with-matches --perl-regexp '\r' HEAD ( Hinweis: auf Windows-Clients funktioniert nur durch git-bash und auf Linux-Clients nur bei Verwendung von --with-libpcre in ./configure kompiliert).
  • Wenn Sie diese Dateien finden, indem Sie den obigen Befehl ausgeführt wird, korrigieren.
  • Verwenden Sie nur das Nötigste .gitattributes
  • Weisen Sie die Benutzer die core.autocrlf oben auf die Standardwerte beschrieben eingestellt werden.
  • Zählen Sie nicht zu 100% auf die Anwesenheit von .gitattributes. git-Clients von IDEs ignorieren sie oder behandeln sie differrently.

Wie gesagt einige Dinge können in git Attribute hinzugefügt werden: 

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Ich glaube, einige andere sichere Optionen für .gitattributes stattdessen die automatische Erkennung für binäre Dateien zu verwenden:

  • -text (z für *.zip oder *.jpg Dateien:.. Wird nicht als Text behandelt werden, also keine Zeilenende Umwandlungen versucht wird Diff durch Konvertierungsprogramme möglich sein könnte)
  • text !eol (beispielsweise für *.java, *.html: Behandelte als Text,aber EOL Stil Präferenz ist nicht gesetzt. So Client Einstellung verwendet wird.)
  • -text -diff -merge (z für *.hugefile. Nicht als Text behandelt Kein Diff / Merge möglich)

--- PREVIOUS UPDATE ---

Ein painful Beispiel ein Kunde, die Dateien zu Unrecht begehen wird:

netbeans 8.2 (Windows), wird fälschlicherweise alle Textdateien begehen mit CRLFs, es sei denn, Sie haben explizit gesetzt core.autocrlf als global . Dies steht im Widerspruch zu dem Standard-Git-Client Verhalten und verursacht viele Probleme später, während der Aktualisierung / Verschmelzung. Dies ist, was einige macht Dateien unterschiedlich erscheinen (obwohl sie nicht sind) , auch wenn Sie zurückkommen .
Das gleiche Verhalten in Netbeans geschieht, selbst wenn Sie richtig .gitattributes zu einem Projekt hinzugefügt haben.

Mit dem folgenden Befehl nach einem Commit, wird zumindest helfen Sie frühzeitig erkennen, ob Ihre git Repo-Linie hat Probleme endet: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top