Hm, I wouldn't call it wrong on many levels, I think it's quite elegant. It's a form of a Merkle Tree, and knowing the hash of a commit does not just allow you to verify its content, but also the whole history up to that point (as the commit contains the hash of its parent, which in turn contains hashes of its content and parents). I guess that's not too unimportant if you consider scenarios where you pull code from distributed repositories (like forks), as you can ensure that the parts of the history you know are actually what they claim to be. And if you accept hash-then-sign as being secure, this is just as secure for signed commits (assuming the hash function is secure).

I think the only unfortunate part here is that git ended up using SHA-1 as a hash function, which 20 years ago might or might not have been a reasonable choice -- I don't know how "broken" it was regarded back then, or how widespread SHA-256 use was.