Each git commit is attributed a hash which "signs" its content. Does it also sign where the commit came from or is it just the commit data itself which is used for the hash calculation?
Differently phrased: is it impossible (apart from hash collisions) to forge a second repository with its head commit having the exact same hash and same content but the rest of the tree differing?
The answer to the second question is yes (it is impossible, etc).
The first question is not as well formed as I think you might want, because a commit hash is in fact just based on the commit data. The key that causes the second question's answer is that "the commit data" includes these key items, which you can see in an actual commit:
$ git cat-file -p HEAD
tree 22abd5c3fed5e2f49fb71e10b39d8c4929e51fc7
parent 4ebdeb68ba87282f87c39d790ba17fe1e021cc97
parent 9eabf5b536662000f79978c4d1b6e4eff5c8d785
[snip]
The tree line gives the hash of the tree (which depends only on the tree contents) and the parent lines—two, in this case, as HEAD is a merge commit—give the hashes of the parent commits. Given that the hash of the current commit depends on the hash(es) of its tree and parent(s), if you were to construct a different repo with a different history or different tree, those would have different hashes so that the commit would also have a different hash.
(The technical term usually used here is Merkle Tree.)
