Why does git rebase --onto b, git rebase --onto ba create another SHA1 from the original?

Question

Suppose you have the following change schedule, c is the current branch:

ca \ / b 

git rebase --onto ab creates the following:

  c / a / b 

and git rebase --onto ba returns a graph:

 ca \ / b 

However, the new SHA1 of c is different from the old SHA1 c, before both settings. Why is this so?

Answer 1

The SHA1 commit depends on everything related to commit, including metadata. In particular, this depends on the commit timestamp. Your double-combined commit has a new timestamp, so it has a new SHA1.

(Note that there was an “author date” when it was originally written, and a “commit date” when the actual commit was committed, only the last one has changed. To verify this, use git log --pretty=fuller , or simply look at the commit in gitk .)