git svn rebase: Unvollständige Daten: Delta-Quelle wurde unerwartet beendet

ich habe gewartet der Git-Spiegel von das Wasserprojekt. Vor einigen Wochen hatten wir jemanden, der bereit war, seinen ersten git-basierten Patch einzureichen. Leider sind wir aufgrund der Multiplattform-Natur des Projekts auf einige Probleme bezüglich der Zeilenenden (CRLF vs. LF usw.) gestoßen.

Ich habe versucht, was ich einstellen konnte die autocrlf-Option (zu ‘Eingabe’) und einige –hard-Resets durchführen. Ein paar Tage später gibt das tägliche Update (git svn rebase) jedoch diesen Fehler aus:

Incomplete data: Delta source ended unexpectedly

Ich habe versucht zu googeln, was zu tun ist, aber selbst das Entfernen der autocrlf-Einstellung in der .git/config hat nicht geholfen. Ich befürchte, dass die Arbeitskopie beschädigt ist, hoffe aber, dass sie nicht wiederhergestellt werden kann.

Natürlich ist eine mögliche Vorgehensweise, einfach von svn neu zu importieren und einen neuen Mirror zu starten, aber ich hoffe, wir müssen das nicht tun, da der aktuelle Watir-Mirror bereits gegabelt wurde und die Leute neuen Code entwickelt haben in ihren Gabeln.

Danke im Voraus für jede Hilfe.

Ich hatte das gleiche Problem beim Versuch, ein Git-Repository aus dem brlcad svn-Repository zu erstellen. Ich habe es gelöst, indem ich getan habe git svn reset --r XXXXX, wobei ich XXXXX auf etwa 50 Revisionen vor der Revision gesetzt habe, die ursprünglich den Fehler erzeugte.

Beim Zurücksetzen einer einzelnen Revision konnte der Fehler nicht behoben werden. Als Teil des Prozesses habe ich Fehler von git erhalten, dass HEAD nicht definiert wurde. Um dies zu beheben, habe ich a git svn find-rev XXXXX um den Hash zu bestimmen, der der gewünschten Revision entspricht, dann git checkout. Danach waren die Fehler über HEAD weg und die git svn reset -r XXXXX hat funktioniert.

Aus eigener Erfahrung generiert git-svn beim Klonen oder Abrufen aus einem svn-Repository mit denselben Parametern immer genau die gleichen Commits (versuchen Sie es: Erstellen Sie ein Dummy-Repository, klonen Sie es mit git-svn, machen Sie weitere Commits, klonen Sie es erneut, und holen Sie die erste Kopie ab; die resultierenden Commits sollten genau den gleichen Hash haben).

Dies bietet Ihnen eine interessante Option: Sie können einen separaten neuen Spiegel mit denselben Parametern starten und beide vergleichen, um zu sehen, wo sie divergieren (oder wenn sie überhaupt divergieren; vergleichen Sie unbedingt die Hashes, da sie wichtig sind). Wenn sie gleich sind (oder Sie entscheiden, dass die Commits, nachdem sie divergieren, keine Rolle spielen), können Sie den neuen Spiegel verwenden, ohne die Forks zu brechen (oder weniger von ihnen zu brechen, wenn Sie sich entschieden haben, einige divergierende Commits zu ignorieren).

Ich hatte das gleiche Problem mit git svn fetch, aber der Reset-Ansatz hat bei mir nicht funktioniert, vielleicht weil ich nicht wirklich weiß, wann die Beschädigung aufgetreten ist. Hier ist, was bei mir endlich funktioniert hat. Ich habe ein git svn fetch --ignore-paths="/branches/" die ohne Fehler lief. Danach habe ich noch einmal meine git svn fetch, und diesmal hat es funktioniert.

Ich hatte das gleiche Problem und wie bei Todd wurde das Problem durch eine vorherige Revision behoben.

Ich denke, die Lösung besteht darin, zu zwei Schritten vor der Revision der problematischen Datei zu gehen.

Ich habe ein ähnliches Problem gesehen. Es tritt auf, wenn ich einen teilweisen Klon eines SVN-Repos mache. Ich vermute, git-svn kann die ursprüngliche Quelle der Datei bei einem dcommit nicht finden. Ich habe es behoben, indem ich sichergestellt habe, dass ich vollständig auf dem neuesten Stand bin (git svn rebase) und dann git svn set-tree verwendet habe, um bestimmte Änderungen an Subversion vorzunehmen. Wenn Sie viele Änderungen festschreiben müssen, kann dies mühsam sein, da Sie jede Änderung der Reihe nach manuell festschreiben müssen, aber es funktioniert gut, wenn Sie nur ein oder zwei Festschreibungen übertragen müssen.