15

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

bm842
  • 369
  • 2
  • 10

1 Answers1

14

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.

Brighid McDonnell
  • 4,293
  • 4
  • 36
  • 61
Sylvain Defresne
  • 42,429
  • 12
  • 75
  • 85
  • 1
    All tree, parents, emails, dates, names from author and committer were reported. Meanwhile, your suggestion to use `git cat-file` helped as I am seeing an extra '\n' in the logged comments, while I do not see any difference with `git show`. I am checking this. – bm842 Apr 12 '11 at 09:32
  • 1
    I've seen that some tool sometime add an extra empty line at the end of the commit message when there is none (so that it ends with an empty line). Maybe this is what happens in your case? – Sylvain Defresne Apr 12 '11 at 09:35
  • I confirm my script wrongly added a newline. I fixed that and have the same sha1 now. Thank you Sylvain. – bm842 Apr 12 '11 at 09:51