Warum lässt "git rebase" gegenüberliegende Sätze von Änderungen in der Bühne und der Arbeitskopie?
Ich benutze git-svn als Svn-Client. Von Zeit zu Zeit stoße ich auf das folgende Problem.
-
Ich beginne mit ein paar Commits in meinem lokalen Git-Zweig, einer leeren Bühne und einer sauberen Arbeitskopie.
-
Ich gebe "git svn rebase" in der Windows-Befehlszeile ein, um die Änderungen des Teams abzurufen und meine Commits nach ihnen zu setzen, um einen linearen Verlauf zu behalten (dies ist erforderlich, um git-svn zu verwenden)
-
Alles geht gut, der Inhalt des Teams wird abgerufen und meine Commits werden nachher rebasiert, aber ...
Am Ende habe ich Änderungen in der Arbeitskopie und modifizierte Dateien in der Bühne, und die Änderungen der Arbeitskopie sind genau das Gegenteil der Änderungen in der Bühne.
I Normalerweise umgehen Sie das, indem Sie einfach alles aufheben, was auf der Bühne ist. Dadurch werden die Änderungen in der Arbeitskopie rückgängig gemacht. Das ist in Ordnung, aber ich würde gerne verstehen, was hier passiert.
Frage: Ist das ein Fehler, oder verstehe ich etwas nicht mit git rebase?
Hinweis: Ich hatte das Problem bei der Verwendung von "git svn fetch" und "git rebase" später.
Hinweis: Ich benutze Git in Windows mit einem großen SVN-Repository (10000 + Dateien, 150000 + Revisionen), und ich verwende auch git-Erweiterungen. Bearbeiten: Ich verwende es nur das Repository zu erkunden und zu committen. Ich mache alles andere von Windows-Befehlszeile.
Bearbeiten: Wie von einem der Kommentare angefordert, finden Sie hier zwei Screenshots zum besseren Verständnis des Problems. Der erste ist der Inhalt der Arbeitskopie, der zweite ist der Inhalt der Bühne. Sie können leicht sehen, dass beide das genaue Gegenteil sind:
Arbeitskopie:
Stage (setzt die Änderungen der Arbeitskopie zurück, sehr visuell: dasselbe Bild, Rot und Grün werden vertauscht):
Bearbeiten: Ich habe das Problem einfach in einem sehr einfachen Fall reproduziert: Mein commit ändert nur eine Datei, sehr wenige neue Commits wurden während der "git svn rebase" geholt, und keiner von ihnen hat Auswirkungen auf die geänderte Datei. Ich habe mit "gitk --all" gecheckt. Es sagt genau dasselbe wie git-extensions und "git status" Hier ist die Ausgabe von gitk. Wir sehen von unten nach oben:
- Die letzten 3 Zeilen sind die 3 Commits, die beim Rebasing abgerufen wurden. Keiner von ihnen berührt meine Datei.
- Die dritte Zeile von oben zeigt mein Commit nach der Rebase: Es ist alles gut, es fügt hinzu, was es hinzufügen soll und entfernt, was es entfernen soll.
- Die zweite Zeile zeigt den Inhalt des Indexes: Er enthält Änderungen, die meinen Commit rückgängig machen
- Die erste Zeile zeigt den Inhalt der Arbeitskopie: Sie enthält die gleichen Änderungen, die mein Commit durchführt, IE kehrt die Änderung im Index zurück.
Bearbeiten: Hier ist der Inhalt von .git dir nach einem "git svn rebase", wo das Problem aufgetreten ist:
Bearbeiten: Wenn Sie daran interessiert sind, dieses Problem zu verfolgen, habe ich einen Fehler auf der Mailingliste [email protected] mit dem Eintrag "[git-svn] [Fehlerbericht]" in einem seltsamen Zustand gemeldet nach git svn rebase "im Betreff.
1 Antwort
Dies scheint ein Fehler zu sein. Wenn Ihr Arbeitsverzeichnis und Index vor einer Rebase sauber sind, sollten sie nach der Rebase sauber sein. oder Sie sollten einen Zusammenführungskonflikt und die Möglichkeit, es zu bereinigen und die Rebase fortzusetzen.
Aus irgendeinem Grund sieht es so aus, als ob Ihr Index nach dem Anwenden Ihrer lokalen Änderungen veraltet ist.
Grundsätzlich gibt es drei Hauptansichten des aktuellen Zustands des Repositorys. Es gibt den HEAD-Commit, bei dem es sich um den Status des Repository beim letzten Commit handelt, und um was für einen nächsten Commit es sich handelt. Dies wird während Ihrer Anmeldung korrekt aktualisiert. HEAD ist jetzt Ihr lokaler Commit, basierend auf dem, was Sie vom Upstream-Repository erhalten haben.
Da ist der Index, der eine Sicht auf den Status Ihres nächsten Commits enthalten soll. Hier scheint das Problem zu liegen. Nach einer erfolgreichen Umbenennung von einer sauberen Struktur sollte der Index die gleiche Ansicht des Repositorys wie HEAD aufweisen, aber anscheinend eine veraltete Ansicht dessen, was das Upstream-Repository enthält. Es scheint, dass es nicht aktualisiert wird, nachdem Sie Ihre lokalen Patches auf das Upstream-Repository angewendet haben.
Und da ist deine Arbeitskopie; die tatsächlichen Dateien auf Ihrer Festplatte. Aus irgendeinem Grund wird bei der Rebase die Kopfzuweisung ordnungsgemäß aktualisiert, und die Arbeitsstruktur wird ordnungsgemäß aktualisiert (oder wird in Ruhe gelassen), aber der Index verbleibt in einem Zustand, der sich auf die Ursprungszuweisung bezieht auf die du dich zurückziehst. Das heißt, wenn Sie den Index mit Ihrem umgestalteten Commit vergleichen, sieht es so aus, als hätten Sie Ihre Änderungen rückgängig gemacht. Wenn Sie Ihre Arbeitskopie mit Ihrem Index vergleichen, sieht es so aus, als hätten Sie sie wieder hinzugefügt.
Ein paar Dinge zu überprüfen:
- Können Sie uns den Inhalt Ihres
.git-Verzeichnisses nach einer solchen problematischen Rebase zeigen? Nur eine Liste der Dateien auf der obersten Ebene von.gitwäre hilfreich. Tatsächlich kann eine vollständige Liste mit Dateinamen, Änderungsdaten und Berechtigungen ein wenig mehr Informationen liefern. - Verwenden Sie dies über irgendein Netzwerk-Dateisystem oder irgendetwas anderes seltsam? Netzwerk-Dateisysteme haben manchmal Probleme, bei denen Dateien veraltet bleiben; Ich frage mich, ob dir das passiert.
- Welche Version von Git verwendest du?
Tags und Links git svn git-svn git-rebase git-stage