Ich versuche ein Commit, das bei HEAD ist, in ein paar zu zerquetschen. Wenn ich git rebase -i HEAD~7 starte, wird mir jedoch nur ein noop im Editor angezeigt! Ich bin total verwirrt darüber, wie das funktionieren soll.
Ich arbeite in einer Zweigstelle ( cleanup ), die ich erstellt habe (mit checkout -b cleanup ... auf der SHA1, die ich in reflog gefunden habe), nachdem ich meine erste rebase -Erfahrung gemacht hatte und versehentlich alle diese Commits gelöscht habe; Punkt ist, ich bin mir nicht sicher, was der Elternteil der Filiale ist (wenn das hier zählt).
Ich versuche einfach, das zu tun, was ich schon oft gelesen habe: Ich möchte etwas Commited-Code ändern, der nicht der letzte Commit ist. Ob das eine Anwendung für das "Quetschen" ist oder ob ich es nur ändern möchte, wenn ich an diesen Punkt komme, weiß ich nicht.
Ich sehe das auch in STDOUT, da der Editor nach dem Ausführen des oben gezeigten Rebase-Befehls startet:
%Vor% Zusätzlich zur HEAD~7 -Referenz habe ich versucht, den gesamten SHA1 und verschiedene refspecs für lokale und entfernte Zweige anzugeben. Das gleiche Ergebnis für alles ...
Was vermisse ich? Danke für Ihre Hilfe!
Es ist die bacbeb2 commit, die ich mit dem d0fd20e
Nach der Empfehlung von @MarkLongair habe ich set -x zu /usr/lib/git-core/git-rebase--interactive hinzugefügt und die folgende seltsame Ausgabe gesehen:
Ich sage "seltsame Ausgabe", denn wenn ich den Befehl rev-list direkt von meiner Shell aus starte, funktioniert es wie erwartet:
Dieses Problem wurde verursacht durch meine .bashrc Einstellung IFS:
%Vor%Ich kann mich überhaupt nicht daran erinnern, warum ich das hier hineingelegt habe. Ich bin mir sicher, dass es etwas damit zu tun hatte, "UNIX- / Linux-Dateinamen zu reparieren", wie durch meine Aufnahme dieser URL angezeigt. Keine Ahnung.
Trotzdem habe ich diese Aussage entfernt und: POOF! Kein Problem mehr!
Vielen Dank an @MarkLongair für seine Hilfe!
Update: Es gibt eine Erklärung für dieses Verhalten am Ende meiner Antwort, aber ich habe die Debugging-Vorschläge hier gelassen, falls sie für irgendjemanden von Nutzen sind.
Ich bin mir nicht sicher, ob ich hier wirklich eine Antwort habe, aber ich werde erklären, was mit meinem besten Verständnis geschieht. Wenn sie als git rebase -i HEAD~7 aufgerufen wird, sollte git nur noop auf .git/rebase-merge/git-rebase-todo ausgeben, wenn diese Datei leer ist oder nicht existiert. Wir wissen, dass dies kein Berechtigungsproblem ist, da diese Datei (mit "noop" und den kommentierten Zeilen) erfolgreich erstellt wurde. Die Tatsache, dass Sie einen Fehler von git rev-list auf dem Terminal sehen, deutet auch darauf hin, dass das Problem tatsächlich darauf zurückzuführen ist, wie git rev-list aufgerufen wurde. In git v1.7.4.1, mit der von Ihnen zitierten Befehlszeile, sollte die Liste der einzubeziehenden Commits aus folgendem stammen:
Beachten Sie, dass dies etwas anders ist als von der Manpage ( git log <upstream>..HEAD ) vorgeschlagen, da der Bereich ... anstelle von ..
Ich würde raten, da Sie einen Fehler von git rev-list sehen, dass dies der problematische Befehl ist. Könnten Sie das versuchen und sehen, was die Ausgabe ist? Wenn dies zu funktionieren scheint, vermute ich, dass ein früherer Fehler vorliegt, der dazu führt, dass diese Befehlszeile fehlerhaft ist. Da die interaktive Rebase als Shell-Skript implementiert ist, können Sie dies relativ leicht untersuchen, indem Sie das Skript mit sudo editor /usr/lib/git-core/git-rebase--interactive bearbeiten und oben set -x hinzufügen, etwa wie folgt:
Wenn Sie versuchen, git rebase -i HEAD~7 auszuführen, sollten Sie alle Befehle sehen, die das Skript ausführt, und möglicherweise sehen, was mit dem Aufruf git rev-list falsch ist.
Ich hoffe, dass das eine Hilfe ist.
Aktualisierung: Es stellt sich heraus, dass das Problem hier war, dass der Fragesteller IFS so eingestellt hatte, dass er nur Tabulatoren und Zeilenumbrüche enthielt, anstatt den Standard von Leerzeichen, Tabulatoren und Zeilenumbrüchen.
Dies verursacht ein Problem in der Zeile in git-rebase--interactive Anfang:
... da MERGES_OPTION auf --no-merges --cherry-pick gesetzt ist. Mit dem Standardwert von IFS (der Leerzeichen enthält) wird dieser nach dem Ersetzen der Variablen in zwei Parameter aufgeteilt. Mit IFS , das kein Leerzeichen enthält, wird --no-merges --cherry-pick jedoch als ein einzelnes und ein offensichtlich unbekanntes Argument interpretiert, wodurch die git rev-list usage-Nachricht und die leere Ausgabe weitergeleitet werden im Skript.
Ein gutes Puzzle:)
Tags und Links git version-control rebase