Reputation: 91
Soon sourceforge will restore my projects git repository.
I have a 'pull -a' from the day before it disappeared; so I am confident that I have no data loss on my local copy.
Would I would like to do is do a "deep compare" of my local copy with the soon-to-be.restored sourceforge master repo so as to make sure that we are absolutely in sync before commit any new changes. Test that the histories agree; the same objects with the same hashes; and anything else that might prevent future grief.
Something like (a non-existent) "git compare-trees --verify ...."
I suppose it might be easier to rename the sourceforge repo, and then push my local copy as the new master, but that strikes me as inelegant.
Upvotes: 2
Views: 1443
Reputation: 488203
As others mentioned in comments, you really just need to check the SHA-1 values (and run git fsck
to make it compare the SHA-1 name by which each object is found, to the current SHA-1 of each object1).
Because git uses a form of Merkle Tree, if the SHA-1 for a branch like master
in one repo matches the SHA-1 for a branch in another repo, you can be reasonably sure2 that the entire chain of commits is bit-for-bit identical in both repositories. Hence comparing the output of a simple git for-each-ref
run on each repository will do the trick.
1If these don't match internally, you'll see (from the git-fsck documentation):
sha1 mismatch <object>
The database has an object who’s sha1 doesn’t match the database
value. This indicates a serious data integrity problem.
2The chance of an accidental match between any two SHA-1s for different inputs is one in 2160 (2160 is a bit over 1048, so this is one in 1.465 quindecillion). As the number of objects rises, the chance rises rapidly due to the "birthday problem" but for practical purposes, it's rare enough to disregard entirely. The only way to get a real collision is to do it on purpose, and that's still too hard.
Upvotes: 3