In einer linearen Historie können zwei Commits A und B einen von drei Zuständen haben:
Git's nichtlinearer Verlauf erlaubt vier zusätzliche Optionen
Ich bin mir nicht sicher, wie ich die letzten zwei erreichen kann, ohne Transplantationspunkte zu verwenden, aber könnte passieren.
Was mir nicht klar ist, wie ich es schaffen soll, ist eine Bestimmung dieser Beziehung auf eine einfache Art und Weise - im Moment kann ich nur an eine etwas seltsame rev-list und Lösung denken, bei der man jeden Fall einzeln testet:
Es muss einen besseren, gierigeren Weg geben, dies zu tun, also was ist es?
Die Suche nach Eltern-Kind-Beziehungen ist einfach, verwenden Sie git merge-base . Wenn das Ergebnis eines Ihrer Commits ist, ist es ein Elternteil, das andere ist ein Kind.
Ich schlage vor, den Fall zu ignorieren, wenn die Commits keinen gemeinsamen Vorfahren haben. Sicher, das kann passieren, aber mir sind keine gültigen Anwendungsfälle bekannt. Ich meine, Sie lösen ein echtes Problem für ein echtes Projekt, ich bin sicher, dass Sie davon ausgehen können, dass dies nicht passieren wird. BTW, merge-base wird mit einem Fehler beendet, und es ist die einzige Situation, in der eine Merge-Base nicht existiert, so dass Sie diesen Fall immer noch erkennen können.
Kinder für ein Commit zu finden ist einfach unmöglich. Absolut. Das kannst du nicht zuverlässig tun. Ein Commit hat eine "Eltern" -Referenz, aber keine "Kind" -Referenzen. rev-list --children macht eine ganz andere Sache, es hat nichts damit zu tun, was Sie wollen. Sie müssen Ihr Problem verfeinern.
Was ich stattdessen vorschlagen kann, ist git branch --contains <commit> oder git tag --contains <commit> , das nur jene Zweige / Tags auflistet, von denen Sie Ihr Commit erreichen können.
Alternativ können Sie sich auch git for-each-ref Damit können Sie testen, ob ein Commit von einem Ihrer Zweige / Tags aus erreichbar ist.