Why does git rebase --onto a b, git rebase --onto b a create a different SHA1 from the original?

Suppose you have the followin开发者_JAVA技巧g revision graph, with c as the current branch:

c   a
 \ /
  b

git rebase --onto a b creates the following:

    c
   /
  a
 /
b

and git rebase --onto b a returns the graph to:

c   a
 \ /
  b

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

The SHA1 of a commit depends on everything about the commit, including the metadata. In particular, it depends on the commit timestamp. Your twice-rebased commit has a new timestamp, so it has a new SHA1.

(Note that there's an "author date", when it was originally written, and a "commiter date", when the actual commit was recorded. Only the latter has changed. To see this for yourself, use git log --pretty=fuller, or just look at the commit in gitk.)