After re-write of a subtree history from a repository with a script of mine, I compared it with what would do a git filter-branch ... on that same subtree. I see that initial commits have different sha1 although I expected them to be identical (consequence of this is that all commits from both histories have different sha1).
Doing a git show --format=raw <commit-sha1> on both commits gives exactly the same output (except for first line, which is commit <commit-sha1>, introducing the result).
Object files are completely different, but as they are binaries, I can't figure out the root cause.
Assuming all git versions are consistent with each other, what could explain to have 2 different sha1?
Thank you
Git's inputs to a commit hash include metadata such as the SHA1 of the tree, the SHA1 of the parent, the commiter's name, email and commit date, and the author's name, email and commit date. So when you rewrote history, the commiter commit date and the tree (since you did a filter-branch) have probably changed, hence the difference in your commit's SHA1.
For more information about the format of a commit, you can use git cat-file commit <sha>, or look up the Git Objects section of the Git Book.
来源：https://stackoverflow.com/questions/5632520/apparently-same-commits-give-different-sha1-why