2015-08-10 5 views
5

Wenn zwei Zweige im selben Quellcode-Zustand übereinstimmen, haseln sie normalerweise gleich und erscheinen zusammen kollabiert. Aber ich habe mich in einem interessanten Zustand (beschrieben im Titel) wiedergefunden.zwei Zweige, die mit git diff gleich sind, aber unterschiedliche Hashes haben

Hier ist, wie ich dort angekommen bin. Ich hatte einen alten Zweig von letzter Woche, und ich habe viele Änderungen vom Meister darin verschmolzen. An diesem Punkt war es ein Schnellvorlauf und außerdem gab es keinen Unterschied zum Master.

Aber wenn ich einen Funktionszweig in diesen Zweig verschmolzen (was ziemlich viel ist den gleichen Zustand wie Meister hatte) endete es wie folgt auf:

* b0dc045 - (new-branch) refactored it. seems to work fine 
| * 4b89219 - (HEAD -> feature, origin/feature) refactored it. seems to work fine 
|/ 
* Merge branch 'master' into 'feature' 
|\ 
... 

‚Master‘ Art und Weise irgendwo da unten ist ...

So irgendwie, zeigt git diff new-branch feature keine diff ... aber sie haben unterschiedliche Hashes .....

Was sind einige Dinge, die ich überprüfen kann wirklich sehen, wo sie wirklich unterscheiden?

Update:

Ich denke, Aspekte der Geschichte eines Zweiges wird in dem Satz von Daten enthalten, die den Hash erzeugt. Dies würde die Disparität erklären.

Also habe ich einen schnellen und schmutzigen Trick

$ diff <(git log new-branch) <(git log feature) 
1c1 
< commit b0dc045b82cfc2f7060ccd3b28dd1b1ca1cf2a59 
--- 
> commit 4b8921960cc8f1d42e3e4d1b505228a2dc0c0638 

Es zeigt, dass der Hash in der ersten Zeile unterscheidet. Dies ist der Teil, der rätselhaft ist. Es zeigt auch, dass der Rest des 24.000 Zeilen Git Logs identisch ist.

+0

@AbeVoelker Sie haben mich aufgefordert, die Git-Logs zu überprüfen, und ich gehe davon aus, dass das Protokollformat alle Autor und Datum Werte zeigt. Sie sind identisch. –

+1

Ich denke, du könntest 'git cat-file -p new-branch' vs' git cat-file -p feature' sehen, um Autor/Committer-Name/E-Mail/Daten zu sehen. – larsks

Antwort

2

Das liegt daran, dass die Commit-Nachricht, Zeit, Autor und Eltern-Commit-IDs ein Teil des Hash sind. Dies stellt sicher, dass niemand diese Felder ändern kann, nachdem ein Commit veröffentlicht wurde und weitere Entwicklungen darüber durchgeführt wurden.

Aber natürlich können Sie auch den gleichen Status mit so vielen verschiedenen Autoren, Commit-Zeiten, Nachrichten und Historien wie Sie möchten erneut eingeben. Jedes Mal erhalten Sie einen anderen Hash und damit einen weiteren Commit, der keine inhaltlichen Unterschiede aufweist.

2

Kredit geht an @larsks für die Befehle

$ git cat-file -p new-branch; git cat-file -p feature; 
tree 26e6e56076b5578100857218df0cbed7fcab10a3 
parent 72f868f7fd45ecabef78cab23f120d48a04bf38d 
author Steven Lu (PuTTY Win7 on Centos 7 VM Feb26[tmux]) <[email protected]> 1439228778 -0400 
committer Steven Lu (Centos 7 VM Feb26) <[email protected]> 1439230770 -0400 

refactored it. seems to work fine 
tree 26e6e56076b5578100857218df0cbed7fcab10a3 
parent 72f868f7fd45ecabef78cab23f120d48a04bf38d 
author Steven Lu (PuTTY Win7 on Centos 7 VM Feb26[tmux]) <[email protected]> 1439228778 -0400 
committer Steven Lu (Centos 7 VM Feb26) <[email protected]> 1439228778 -0400 

refactored it. seems to work fine 

Das Delta ist in der Committer Zeit von new-branch.

Das ist craaaaazy maaaaan.

+0

Nicht verrückt. Das einzig richtige zu tun. Es ermöglicht Ihnen zu beweisen, was Ihre Systemzeit war, als Sie Ihre Arbeit begangen haben. Zusammen mit weiteren, später von verschiedenen Autoren gemachten Zusagen gibt dies einen sehr stichhaltigen Beweis für die Zeit, in der die Arbeit gemacht wurde, ein Beweis, der sogar vor Gericht gültig sein sollte. – cmaster

Verwandte Themen