git log nicht chronologisch geordnet

Von die Dokumentation für git log :

  

- Grafik

     

Zeichnen Sie eine textbasierte grafische Darstellung des Commit-Verlaufs auf der linken Seite der Ausgabe. Dies kann dazu führen, dass zusätzliche Zeilen zwischen den Commits gedruckt werden, damit der Graphverlauf korrekt gezeichnet wird.

     

[...]

     

Dies bedeutet standardmäßig die Option --topo-order , aber es kann auch die Option --date-order angegeben werden.

Und wenn wir uns die Dokumentation für die Option --topo-order anschauen:

  

- Topo-Reihenfolge

     

Zeigen Sie keine übergeordneten Elemente an, bevor alle ihre untergeordneten Elemente angezeigt werden , und vermeiden Sie es, Commits für mehrere Zeilen der Historie anzuzeigen, die miteinander vermischt sind.

     

Zum Beispiel in einem Commit-Verlauf wie folgt:

%Vor%      

wobei die Zahlen die Reihenfolge der Commit-Zeitstempel angeben, git rev-list und Freunde mit --date-order die Commits in der Reihenfolge der Zeitstempel anzeigen: 8 7 6 5 4 3 2 1.

     

Mit --topo-order würden sie 8 6 5 3 7 4 2 1 (oder 8 7 4 2 6 5 3 1) anzeigen; einige ältere Commits werden vor neueren Commits angezeigt, um zu vermeiden, dass die Commits zweier paralleler Entwicklungstracks zusammen angezeigt werden.

Also, weil Sie git log mit --graph verwenden, werden neuere Commits immer unter ihren Kindern angeordnet. Wenn Sie also ein älteres Commit haben, das ein Kind eines neueren Commits ist, wird git log --graph das ältere Commit über dem neueren Commit anzeigen.

Wie kann das passieren? Wie ist es möglich, dass ein Commit (d4bb883) ein älteres Commit-Datum hat als sein direktes Parent? Müsste der Elternteil nicht zuerst begangen werden müssen? Nun, Commit-Zeitstempel sind nur Metadaten, die von Git zu Commits hinzugefügt werden, und aufgrund der verteilten Natur von Git gibt es nichts, was die Commiters davon abhält, das gewünschte Datum für die von ihnen erstellten Commits festzulegen. Tatsächlich verfügt git rebase sogar über Optionen, die es Ihnen explizit erlauben, über Commit-Daten "zu lügen":

  

- Committer-Datum-ist-Autor-Datum

     

- ignore-date

     

Diese Flags werden an git am übergeben, um die Daten der gestaffelten Commits einfach zu ändern (siehe git-am [1] ).

Und git-am s Dokumente sagen:

  

- Committer-Datum-ist-Autor-Datum

     

Standardmäßig zeichnet der Befehl das Datum aus der E-Mail-Nachricht als das Autorisierungsdatum des Commits auf und verwendet den Zeitpunkt der Erstellung des Commits als Committer-Datum. Dies ermöglicht dem Benutzer, über das Committer-Datum zu lügen, indem er denselben Wert wie das Autorendatum verwendet.

Abgesehen von --committer-date-is-author-date gibt es jedoch andere Möglichkeiten, ein Commit-Datum falsch einzustellen, z. B. eine falsch eingestellte Systemuhr auf dem PC des Commiters. Der Punkt ist, Committer Termine werden nicht immer immer genau sein.

Es ist möglich, dass sie ein Bewertungssystem verwenden (Beispiel für ein solches Bewertungssystem: Gerrit ). So können ältere Commits länger im Review sein, so dass es länger dauert, bis sie zusammengeführt werden.

Aus diesem Grund könnten die neueren Commits früher zusammengeführt werden.