alt Hacker News> it is not a logically deductive necessity that we just scan the topmost object and trust the hashes it contains.
It kind of is. Otherwise the whole idea of signing a commit with a backing git history (rather than just a snapshot of a working directory) collapses. The only guarantee you have that the git history is what is claimed by the cryptographic signature is some sort of Merkle tree structure. Either the original one, or you have to construct a whole new parallel one with a better hash, in which case, as I bring up in a cousin comment, why not just use a better hash in your original one?
In a git repo based on SHA-1 hashes, it would be good enough that the meaning of a commit signature is that the content of the commit is attested, not the parents.
Parent commits can have their own signatures, and it's true that there is an attack possible there where the same parent hash could point to two different commits, that have valid signatures of some kind (possibly from the same sneaky developer who is a bona fide project member).
Be that as it may, it's perfectly okay for the signature on a banana to validate only the banana, and not the gorilla that is holding it, or the vine the gorilla is swinging on, and the whole jungle.
It would be worth it to have better quality commit signing for SHA-1-based repos.