2017-01-31 4 views
3

Ich frage mich, ob es möglich ist, zwei Commits mit dem gleichen Hash zu erstellen.Erstellen eines doppelten Git-Commits

Sagen wir einfach, ich bin auf dem Zweig master und ich erstelle einen neuen Zweig namens foo. Nun sagen wir, dass ich zwei Terminalsessions habe, die beide als Autor autorisiert sind: [email protected]. Nehmen wir nun an, dass sich eine Terminal-Sitzung auf master befindet und eine andere Terminal-Sitzung sich auf foo befindet und beide Zweige genau dieselben gestuften Änderungen aufweisen. Angenommen, ich führe den Befehl git commit genau zur selben Zeit in beiden Terminalsitzungen aus ...

Würden die beiden Commits nicht den gleichen Hashwert haben?

+0

beziehen Sie bitte Antworten von http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob – gzh

+0

@ Slava.K ist es ziemlich anders, meine Frage geht nicht darum, wie git die Situation behandeln würde, meine Frage ist, ob Sie die Situation tatsächlich schaffen können. – Ogen

+1

Siehe auch http://stackoverflow.com/questions/25128077/how-does-git-assure-that-commit-sha-keys-for-identical-operations-data-are-still - in Fußnote 1 gebe ich eine Formel um "ungezwungene" Kollisionswahrscheinlichkeiten zu berechnen.Wenn Sie SHA-1 brechen oder teilweise brechen können, können Sie die Wahrscheinlichkeit einer Kollision erhöhen. Selbst wenn Sie einen bekannten zweiten Urbildangriff für allgemeines SHA-1 haben, müssen Sie es möglicherweise modifizieren, um mit Git zu arbeiten. – torek

Antwort

4

Ja, es ist theoretisch möglich, dass Sie auf diese Situation stoßen. Der Commit-Hash wird aus dem Inhalt des Objekts commit erzeugt wird, die sind:

  • Die Commit-Nachricht
  • Der Name des Autors
  • Der Authoring-Zeitstempel
  • Der committer Name
  • der Commit-Zeitstempel
  • Die Liste der Eltern-Commits
  • Die Baumobjekt Referenz

Der Tree Object-Verweis ist ein Objekt-Hash selbst, der aus Referenzen auf Blob-Objekte und Teilbäume besteht. So wird es für einen identischen Baum von Dateien identisch sein.

Wenn also alle diese Eigenschaften des Commits identisch sind, dann würden Sie ja den gleichen Hash erhalten. Dies kann absolut konstruiert werden, wenn Sie denselben Autor und Commit zur genau gleichen Zeit verwenden; Da die Auflösung des Zeitstempels nur in Sekunden erfolgt, müssen Sie nicht einmal so präzise sein.

Aber ist das ein Problem in der Praxis? Nicht wirklich: Sie würden normalerweise nicht mit demselben Benutzer zur gleichen Zeit begehen; stattdessen hätten Sie separate Mitwirkende mit ihrer eigenen Identität, die an ihren eigenen Sachen arbeiten. Die Wahrscheinlichkeit, dass Commits den gleichen Hashwert erhalten, ist also nahe Null.

Aber auch wenn diese Situation in der Praxis passiert. Würde es ein Problem geben? Nein. Die Commits sind per Definition identisch (und nach Konstruktion). Sie sind also gleich. Und sie sind miteinander kompatibel, also wenn du später drückst oder drückst, sieht es so aus, als ob du das schon getan hättest und einfach nichts passiert.

Natürlich gibt es das verbleibende Problem von Hash-Kollisionen aufgrund des begrenzten Hash-Speicherplatzes von SHA1. Dies kann ein mögliches Problem in sehr großen Repositories werden, aber ich habe noch nichts davon gehört noch-obwohl es bereits Repositories von gigantischen Größen gibt. Aber selbst wenn es für einen von ihnen passierte, würde es andere Repositorien mit besser managbaren Größen nicht beeinträchtigen.

+1

Danke, das ist eine gut formulierte Antwort - sehr einfach zu verstehen. Ich habe nie realisiert, dass selbst wenn es passiert wäre, es kein Problem wäre! – Ogen

Verwandte Themen