Was ist das Gegenteil von `git diff HEAD ^`?

Question

In git kann ich die vorherige Version mit oder HEAD~1 angeben. Wie wäre es, in die andere Richtung zu gehen? Angenommen, ich bin auf Revision X und tue git checkout X^. Wie gehe ich zurück?

Etwas wie git checkout X+?

Answer 1

Sie können nicht genau das tun. History in git ist ein gerichteter azyklischer Graph - jedes Commit enthält Verweise auf seine Eltern, aber Eltern haben keine Referenzen auf ihre Kinder.

Das Problem hier sollte offensichtlich werden, wenn Sie an ein Commit denken, von dem Sie mehrere Zweige erstellt haben. Welches "nächste Commit" meinst du? Mit Eltern können Sie eine Nummer angeben (ein normales Zusammenführungs-Commit hat ein erstes und zweites Elternteil), aber wie machen Sie das mit Kindern? Selbst wenn Sie wissen, was Sie Zweig auf sein bist versuchen (zB Sie haben master~4 ausgecheckt und jetzt wollen Sie bei master~3 suchen), ist es nicht gut definiert - Sie in einer Situation wie dieser sein könnte:

- X (HEAD) - o - o - o - Y (master) 
    \     /
    o - o - o ---------- 

das heißt, in einfachen Fällen, könnten Sie so etwas tun:

git checkout $(git rev-list HEAD..master | tail -n 1) 

das wird klar mit linearen Geschichte gut funktionieren. Mit merges ... rev-list arbeitet von Gegenwart zu Vergangenheit in der Geschichte, nach rückwärts. Ich glaube, es folgt der erste Elternteil zuerst, so dass die zuletzt gedruckte Sache das Festschreiben nach HEAD ist, indem man allen letzten Eltern folgt.

Edit: Das setzt voraus, dass Sie wissen, in welchen Zweig Sie sich vorwärts bewegen möchten. Wenn nicht ... na ja, sie ist so ziemlich fest auf allen Refs für Commits suchen, die den aktuellen HEAD als Elternteil haben - wahrscheinlich greppen die Ausgabe von git rev-parse:

git rev-list --all --children | grep ^$(git rev-parse HEAD) 

dann die anderen SHA1 greifen aus die Linie (benutze awk, was auch immer). Sie müssen manuell überprüfen oder eine willkürliche Wahl treffen, wenn es mehrere Ergebnisse gibt ...

Answer 2

Ich glaube nicht, dass dies möglich ist, da ein Git-Commit speichert nur seine Eltern Commit, aber nicht seine Kinder.

Stellen Sie sich vor, ein Commit würde seine Kinder speichern. Was würde passieren, wenn Sie mehrere Zweige von diesem Commit erstellen würden, also haben mehrere Commits dieses Commit als Eltern? Was wäre dann "HEAD +"? Das ist mehrdeutig und falsch.

Sprechen in, was ich aus Datenstrukturen weiß: Git speichert Geschichte als eine Single-Linked-Liste, während Sie Operation eine doppelt verknüpfte Liste benötigen würde.

Answer 3

Soweit ich sagen kann gibt es keine symbolische Möglichkeit, auf die Kinder eines Commit beziehen.

Das Beste, was ich Ihnen jetzt geben kann, ist die --children Option von git rev-list. Hier bitte ich um die letzten vier Commits, die hübsch gedruckt werden sollen, sowie Informationen über ihre Kinder. Beachten Sie, dass in der "commit" -Zeile jedes Eintrags (außer dem letzten) eine zusätzliche Commit-Nummer vorhanden ist, die das Kind dieses Knotens angibt. Sie können entweder manuell oder durch Shell-Skripte greifen, um zum Kind zu gelangen.

$ git rev-list --children --pretty HEAD~3... 

commit 20dba296ad1d48ec90f9319e2c13b245e849f698 
Author: Somebody <____@____.net> 
Date: Thu May 6 19:10:38 2010 -0400 

    Support for complex trig/pow. 

commit 9d42b5bac1721a847a39c25672e577c7101c8ff0 20dba296ad1d48ec90f9319e2c13b245e849f698 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:55:07 2010 -0400 

    Fix doc formatting warning. 

commit 72bed3baa9df71cb224dfa8388b5969d50f5567c 9d42b5bac1721a847a39c25672e577c7101c8ff0 
Merge: b8244cb61491c9cdb83d36e57f8eb49773e44f6b 899c3dd3f9f419f200b84ca0abe59d7ac3d5bb53 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:54:59 2010 -0400 

    Merge branch 'master' 

commit 899c3dd3f9f419f200b84ca0abe59d7ac3d5bb53 72bed3baa9df71cb224dfa8388b5969d50f5567c 
Author: Somebody <____@____.net> 
Date: Wed May 5 21:19:11 2010 -0400 

    Fix link