git rebase -i — warum ändert es Commit-Hashes?

Ich bin also mehr oder weniger damit vertraut, wie Rebasing funktioniert, aber bis vor kurzem habe ich normalerweise nur a gemacht git rebase -i HEAD~20und geändert, was geändert werden musste.

Ich war überrascht zu erfahren, dass dies die Hashes aller 20 Commits ändern wird, selbst wenn die einzige Aktion, die ich ergreife, darin besteht, die letzten beiden zu quetschen.

Ich bin mir jedoch nicht sicher, was die Hash-Änderung für die anderen 18 Commits verursacht, da sich weder ihre Eltern noch ihr Inhalt ändern … Oder doch? Vielleicht ein Zeitstempel?

Gibt es auch eine Möglichkeit, das zu verhindern?

Von dem rebase doc:

Die Commits, die zuvor in den temporären Bereich gespeichert wurden, sind dann erneut auf den aktuellen Zweig angewendeteins nach dem anderen, in der Reihenfolge.

Wenn die Commits “erneut angewendet” werden, wird wirklich ein brandneues Commit erstellt … der Inhalt mag derselbe sein, aber es wird einen anderen Zeitstempel haben Das ist ein Teil davon, wie sein SHA generiert wird … daher werden die neuen Commits einen neuen SHA haben.

Sie können mehr darüber lesen, wie SHAs berechnet werden hier.

Sie haben vielleicht das Gefühl, dass Sie einige Commits nicht geändert haben, aber Sie haben sie tatsächlich auf verschiedene Weise geändert:

• Jeder Commit enthält die sha1 seiner Eltern. Wenn Sie also den sha1 eines übergeordneten Elements ändern, wird der Commit geändert, daher sein sha1. Die Hashes sind verkettet, Änderungen in der Vergangenheit ändern die Zukunft. Technisch nennt man das a Merkle-Baum. Dies ist eine wichtige Eigenschaft von Git, denn bei einem sha1 garantiert es nicht nur die Integrität des aktuellen Commits, sondern auch der gesamten Historie, die dazu geführt hat (vorausgesetzt, Sie können in sha1 keine Kollision finden, was heute nicht mehr wirklich der Fall istaber Kollisionen sind immer noch sehr schwer zu finden).

• Jeder Commit enthält eine Momentaufnahme des aktuellen Status Ihres Projekts. Selbst wenn ein Commit identisch zu sein scheint, weil es denselben Unterschied einführt, entspricht es möglicherweise nicht demselben Zustand des Projekts (demselben Baumobjekt).

• Wie bereits erwähnt, enthalten Commits Zeitstempel (ein Zeitstempel für den Autor, einer für den Commiter, der zweite wird beim Rebase geändert).

Dadurch werden die Hashes aller 20 Commits geändert, selbst wenn die einzige Aktion, die ich ergreife, darin besteht, die letzten beiden zu quetschen.

Wenn Sie mit “die letzten beiden” die letzten beiden Commits in der Historie meinen, dann nein, das wird es nicht.

Bitte seien Sie konkret, zeigen Sie die tatsächlichen Beweise, die Sie sich ansehen, die Todo-Liste, die Sie erhalten haben, und die, die Sie ausgeführt haben. Charakterisierungen sind auch weit unzuverlässiganfällig für nicht freigegebenen Kontext.

Hier ist zum Beispiel, was passiert, wenn ich die letzten beiden Commits zerquetsche, wie ich es verstehe:

$ git log --oneline --reverse @{u}..
00f53a2 echo >master6
afcef3e echo >master7
1f55c48 echo >master8
c3197a0 echo >master9
d30bb35 (HEAD -> master) echo >master10
$ GIT_SEQUENCE_EDITOR='sed -i 5s/pick/squash/' git rebase -i
[detached HEAD 16dc80d] echo >master9
 Date: Mon Feb 5 09:25:55 2018 -0800
 2 files changed, 2 insertions(+)
 create mode 100644 master10
 create mode 100644 master9
Successfully rebased and updated refs/heads/master.
$ git log --oneline --reverse @{u}..
00f53a2 echo >master6
afcef3e echo >master7
1f55c48 echo >master8
16dc80d (HEAD -> master) echo >master9
$ 

Sie können sehen, dass die letzten beiden Commits zusammengequetscht wurden, die IDs aller Commits, deren Verlauf sich nicht geändert hat, bleiben unberührt.

Beachten Sie, dass Git vor Git 2.29 (4. Quartal 2020) auch den Hash des Commits ändern konnte, auf den Sie in der rebasieren todo Nachricht, Commit, die sollte nicht ändern (da Sie alte Commits auf diese wiedergeben).

Sehen Commit 5da69c0 (13.08.2020) von Antti Keränen (Detegr).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in Commit 4499a4219.08.2020)}

rebase -i: Korrigieren Sie möglicherweise falsch auf Hash in todo

^{Gefunden von: Jussi Keränen
Unterzeichnet von: Antti Keränen
Bestätigt von: Alban Gruin}

‘todo_list_write_to_file‘ kann den statischen Puffer überschreiben, der von ‘ stammtfind_unique_abbrev‘, die verwendet wurde, um den kurzen Commit-Hash zu speichern ‘c‘ zum “# Rebase a..b onto c” Nachricht im Todo-Editor.

Dies liegt daran, dass der Puffer, der von ‘find_unique_abbrev‘ gilt bis zu 4 weiteren Aufrufen find_unique_abbrev werden hergestellt.

Wie ‘todo_list_write_to_file‘ Anrufe ‘find_unique_abbrev‘ für jeden rebasierten Commit den Hash für ‘c‘ wird überschrieben, wenn 4 oder mehr Commits in der Rebase vorhanden sind.
Dieses Verhalten wurde seit seiner Einführung gebrochen.

Beheben Sie das Problem, indem Sie den Short-on-Commit-Hash in einem anderen Puffer speichern, der gültig bleibt, bevor Sie ‘ aufrufentodo_list_write_to_file‘.

Dies liegt daran, dass Sie beim interaktiven Rebase des Knotens in HEAD, der 20 Commits vor dem aktuellen liegt, bei dem Knoten in HEAD beginnen, der 20 Commits vor liegt, und die nachfolgenden 20 Commits erneut anwenden, als ob sie neu wären, mit der Option, Änderungen vorzunehmen . Selbst wenn Sie nur Commit -20 und -19 ändern (squash), wenden Sie immer noch die nachfolgenden 18 Commits erneut an, als ob sie neue Commits wären. Sie verwenden nicht denselben Knoten für diese 18 Commits wieder, Sie kopieren ihren Inhalt, hängen aber neue an Ihren rebasierten HEAD an.

Aus dem Git-Buch zum Rebasing:

Denken Sie noch einmal daran, dass dies ein Rebasing-Befehl ist – jeder Commit im Bereich HEAD~3..HEAD wird neu geschrieben, unabhängig davon, ob Sie die Nachricht ändern oder nicht.