Ist es möglich, dass Git-Merge Zeilenende-Unterschiede ignoriert?


Answers

Ich habe nach der gleichen Antwort gesucht und das herausgefunden

Zweige mit unterschiedlichen Checkin- / Checkout-Attributen zusammenführen

Wenn Sie einer Datei Attribute hinzugefügt haben, die dazu führen, dass das kanonische Repository-Format für diese Datei geändert wird, z. B. durch Hinzufügen eines Bereinigungs- / Verschmierungsfilters oder text / eol / ident-Attribute, führt das Zusammenführen normalerweise dazu, dass Konflikte auftreten .

Um diese unnötigen Verschmelzungskonflikte zu vermeiden, kann Git angewiesen werden, beim Lösen einer Dreiwege-Zusammenführung durch Setzen der Konfigurationsvariable merge.renormalize einen virtuellen Check-Out und Check-In aller drei Phasen einer Datei durchzuführen. Dadurch wird verhindert, dass Änderungen, die durch die Check-in-Konvertierung verursacht werden, zu falschen Zusammenführungskonflikten führen, wenn eine konvertierte Datei mit einer nicht konvertierten Datei zusammengeführt wird.

Solange ein "Smudge → clean" die gleiche Ausgabe wie "clean" ergibt, selbst bei bereits verschmutzten Dateien, löst diese Strategie automatisch alle filterbedingten Konflikte. Filter, die sich nicht auf diese Weise verhalten, können zusätzliche Zusammenführungskonflikte verursachen, die manuell gelöst werden müssen.

Wenn Sie diesen Befehl in einem beliebigen Repository ausführen, wird dies der Fall sein:

git merge master -s recursive -X renormalize
Question

Ist es möglich, dass git merge Zeilenende-Unterschiede ignoriert?

Vielleicht stelle ich die falsche Frage ... aber:

Ich habe versucht, config.crlf config.crlf input aber die Dinge wurden ein bisschen unordentlich und außer Kontrolle geraten, besonders wenn ich es nach der Tat anwendete.

Zum einen scheint die Anwendung dieser Konfiguration nach dem Faktum keine Auswirkungen auf Dateien zu haben, die an das Repository gebunden wurden, bevor diese Option angewendet wurde. Eine andere Sache ist, dass plötzlich alle Commits zu vielen nervigen Warnmeldungen über die Umwandlung von CRLF in LF führen.

Um ehrlich zu sein, ist es mir egal, welches Zeilenende verwendet wird, ich persönlich bevorzuge den Unix-Stil \n , aber was auch immer. Alles, was mir wichtig ist, ist, dass git merge etwas schlauer wird und die Unterschiede in den Zeilenenden ignoriert.

Manchmal habe ich zwei identische Dateien, aber Git würde sie als Konflikt markieren (und der Konflikt ist die ganze Datei), einfach weil sie ein anderes Zeilenende-Zeichen verwenden.

Aktualisieren:

Ich habe herausgefunden, dass git diff eine --ignore-space-at-eol akzeptiert, wäre es möglich, git merge auch diese Option verwenden zu lassen?




aber ich schlage vor, Tool wie sed zu verwenden, um korrekte Zeilenenden zu erreichen, und dann Diff-Dateien. Ich verbrachte einige Stunden damit, Projekte mit verschiedenen Zeilenenden zu bearbeiten .

Der beste Weg war:

  1. Kopieren Sie nur Projektdateien ( .git Verzeichnis auslassen) in ein anderes Verzeichnis, erstellen Sie darin ein Repository, fügen Sie dann Dateien hinzu und binden Sie sie ein (sollte sich auf der Hauptverzweigung im neuen Repository befinden).
  2. kopiere Dateien aus dem zweiten Projekt in den gleichen Ordner, aber einen anderen Zweig zum Beispiel dev ( git checkout -b dev ), übergebe Dateien auf diesem Zweig und laufe (wenn das erste Projekt im Master ist): git diff master..dev --names-only um nur die Namen der geänderten Dateien anzuzeigen



AFAICT, (ich habe es nicht ausprobiert) du könntest git diff benutzen, um den Zweig, den du verschmelzen willst, mit dem gemeinsamen Vorfahren zu vergleichen, und dann die Ergebnisse mit git apply . Beide Befehle haben --ignore-whitespace Optionen, um Zeilenende- und --ignore-whitespace zu ignorieren.

Wenn der Patch nicht sauber angewendet wird, wird der gesamte Vorgang leider abgebrochen. Sie können Zusammenführungskonflikte nicht beheben. Es gibt eine Option --reject , um nicht reparierbare Abschnitte in .rej Dateien zu .rej hilft, ist aber nicht dasselbe, als wenn die Zusammenführungskonflikte in einer Datei angezeigt werden.




http://stahlforce.com/dev/index.php?tool=remcrlf

Ich habe es versucht, aber wenn Sie nach der letzten Zeile in Ihrem Code nicht bereits CRLF haben, fügt es selbst ein LF hinzu und die Datei sieht in git verändert aus. Ansonsten funktioniert es.




Wie in dieser Antwort: https://.com/a/5262473/943928

Sie könnten versuchen: git merge -s recursive -Xignore-space-at-eol




"Git merge -Xrenormalize" funktioniert wie ein Zauber.




Links