2016-06-29 16 views
2

Ich habe beschlossen, eine Geschichte, die nie in Git war, rückwirkend von einem anderen alten Versionskontrollsystem zu begehen. Also habe ich einen verwaisten Zweig "newroot" erstellt und Commits von dem anderen Versionskontrollsystem dorthin importiert. Folgende Frage Insert a commit before the root commit in Git?Resolve git Rebase Konflikte auf die gleiche Weise, wie sie zuvor gelöst wurden

Der Zweig "newroot" endete mit Dateien, die exakt mit dem Root-Commit des "Master" -Verzweigs übereinstimmen.

Jetzt möchte ich die „Master“ Zweig auf den „newroot“ orphan Zweig rebase, wie:

git rebase --onto newroot --root master 

Das Problem ist, dass ich aufgefordert erhalten, um alle Konflikte verschmelzen zu lösen. Es gibt Hunderte von Zusammenführungen über eine Zeitspanne von vielen Jahren. Ich bin nur nicht in der Lage, sie manuell zu lösen. Und das ist wirklich nicht nötig, da diese Zusammenführungen bereits in der Vergangenheit gelöst wurden. Da die Rebase den Inhalt eigentlich nicht ändert (da ich auf einen identischen Baum rebasiere), möchte ich, dass Git die "Zusammenführung" genau wiederholt.

Gibt es eine Möglichkeit anzugeben, dass die Rebase die gleiche Auflösung verwenden soll wie zuvor?

Ich habe verstanden, dass die "rerere" hier helfen kann. Aber ich hätte es schon aktivieren müssen, wenn es ursprünglich zusammenfließt, oder? Oder kann ich den Cache "rerere" nachträglich nachbilden?


Ich kann mir eine alternative Lösung für meine Aufgabe vorstellen. Um Git irgendwie zu bitten, die Zweige "newroot" und "master" zu verketten, ohne sie tatsächlich zu reassoziieren. Aber ich bin mir nicht sicher, ob das möglich ist.

Antwort

3

Um Git irgendwie zu bitten, die Zweige "newroot" und "master" zu verketten, ohne tatsächlich zu rebasieren. Aber ich bin mir nicht sicher, ob das möglich ist.

dass ein graft point genannt wird, gefolgt von einer filter-branch um Master Geschichte neu zu schreiben.
Siehe this post as an example oder this question.

Auf der rebase Seite, können Sie versuchen, eine Merge-Strategie wie die ihre verwenden, jeden Konflikt Inhalt unter Verwendung des Master-Zweig zu lösen (da Master indexiert wird)

git rebase --merge -s recursive -X theirs --onto newroot --root master 
+0

Vielen Dank für Ihre Antwort. Der Transplantationspunkt sieht wie die Lösung aus, nach der ich suchte. Kannst du bitte erklären, warum der 'Filter-Zweig' benötigt wird und in Bezug auf den Graft-Punkt? –

+1

@MartinPrikryl Graft-Punkt ist ein rein lokaler Trick, um einen Zweig als Elternteil eines anderen Zweiges zu sehen. Du brauchst einen Filter-Zweig, um diesen Trick dauerhaft zu machen, da jeder SHA1 des Masters seinen neuen Elternteil widerspiegelt, beginnend mit dem ersten Elternteil (der nun den alten importierten Zweig als Eltern haben würde). Auch hier zeigt http://bugsquash.blogspot.fr/2010/03/stitching-git-histories.html ein konkretes Beispiel. – VonC

+0

OK, also füge ich den Graft-Punkt hinzu, und wenn ich den 'filter-branch' anrufe, sieht er den Graft-Punkt und erstellt den Verlauf entsprechend dem Graft-Punkt neu. Danach wird der Transplantationspunkt nicht mehr benötigt. Ist das korrekt? –