Bearbeiten: git spielt nicht mit der Zeichencodierung. Dies ist immer noch hier, um Wissen zu teilen und zu vermeiden, dass andere denselben Fehler machen.
Der Kontext: Mein Unternehmen verwendet ein SVN-Repository. Ich verwende git-svn als Client, um mit diesem Repository zu interagieren. Alle Textdateien im Projekt sind (und müssen) mit der Windows-Standardkodierung (cp-….) kodiert sein. Ich verwende Git-Erweiterungen und manchmal die Befehlszeile, um Git zu steuern.
Was ich getan habe: Während der letzten 3 Tage habe ich an einem neuen Feature gearbeitet und eine Reihe lokaler Commits durchgeführt. Schließlich habe ich alle diese Commits mit einem interaktiven Rebase zu einem einzigen zusammengefasst, dann habe ich git svn dcommit verwendet, um alles in einem einzigen Commit in das SVN-Repository zu pushen.
Was ist dann passiert: Ein Kollege sagte mir, dass alle Akzente in den Dateien, die ich geändert habe, und in den neuen Dateien nach meinem Commit durcheinander waren. Ich hatte bereits Textdateien mit Akzenten im selben Repository mit meiner Installation von git + svn festgeschrieben, und es ist das erste Mal, dass ich mit diesem Problem konfrontiert werde.
Meine Untersuchung: Ich habe die folgenden Dinge untersucht: Ich habe die Dateien mit Notepad ++ geöffnet und die aktuellsten Codierungen (einschließlich Windows-Standard und UTF-8) ausprobiert, um sie anzuzeigen: Keine von ihnen konnte Akzente richtig anzeigen, und verschiedene Akzente werden immer von gerendert dieselbe Folge seltsamer Glyphen.
Die vorübergehende Problemumgehung: Ich habe schnell einen Revert-Commit mit der Git-Erweiterung erstellt und ihn “dcommited”.
Die Frage: Mein Enterprise-SVN-Repository ist in Ordnung, aber jetzt habe ich die beiden folgenden Probleme zu lösen:
- Verstehen Sie, was mit den Zeichen mit Akzent passiert ist
- Meine Arbeit aus dem SVN-Verlauf abrufen und ordnungsgemäß übergeben (wenn möglich, ohne alle Zeichen mit Akzenten manuell zu überprüfen)
Kann jemand einige Hinweise geben (ich bin ziemlich neu in Git)?
Meinen Sie, dass der Inhalt Ihrer Textdateien geändert wurde, nicht die Pfade? (Ich frage, weil ich weiß, dass git-svn mit Dateien wie mit Byte-Arrays arbeitet). Welche Version von git-svn verwendest du?
– Dmitri Pawlenko
16. Mai 2012 um 22:50 Uhr
Ja, es ist der Inhalt der Dateien, der während der Operation geändert wurde, nicht die Pfade. Ich aktualisiere, sobald eine neue Version kommt, aber ich bin gerade nicht bei der Arbeit. Ich werde Ihnen die genauen Versionsnummern von Git und Git-Erweiterungen mitteilen, sobald ich kann
– Samuel Rossille
16. Mai 2012 um 23:02 Uhr
Wenn git-svn dcommits Änderungen an das Repository durchführt, geschieht Folgendes:
– Dmitri Pawlenko
16. Mai 2012 um 23:59 Uhr
Entschuldigung, geben Sie hier einfach den Kommentar ein, den ich nicht kannte. Entweder hat ein interaktives Rebase die Dateien beschädigt oder git-svn. Sie können überprüfen, indem Sie einen temporären Branch (git co; git co -b tmpbranch) für den Commit erstellen, der der letzte war, bevor Sie die interaktive Rebase durchgeführt haben (Sie können alte Commits-IDs mit dem Befehl „git reflog“ finden). , und wiederholen Sie diese interaktive Rebase unter den gleichen Umständen. Prüfen Sie danach, ob Ihre Dateien in Ordnung sind. Bitte teilen Sie mir mit, ob es sich um ein Git-SVN- oder Rebase-Problem handelt.
– Dmitri Pawlenko
17. Mai 2012 um 0:18 Uhr
Git zerstört keine Objekte in Operationen, es fügt nur neue Referenzen ein und aktualisiert sie. Es zerstört sie nur beim Garbage-Collector-Aufruf (obwohl es oft implizit aufgerufen wird, löscht es standardmäßig nicht alle unerreichbaren Objekte). Git hält alle Objekte über Referenzen und Reflogs erreichbar. Aber selbst unerreichbare Objekte (standardmäßig) werden etwa 30 Tage lang nicht erfasst. Nur wenn Sie “git prune” oder “git gc –prune” oder so etwas explizit aufgerufen haben.
– Dmitri Pawlenko
17. Mai 2012 um 0:32 Uhr