> There is no reason that a signing scheme must rely on and trust those hashes!
Not "must", but it would be stupid to use two sets of hashes without a compelling reason.
Not "must", but it would be stupid to use two sets of hashes without a compelling reason.
(Inside GPG, there are configurable choices. It's possible to be using SHA-512, so in a SHA-256 git repo, you can still be using two hashes.)
In our reality, the git hash is load bearing. You can disagree with that design choice, but you can't pretend to live in that alternate reality and design your solutions for this reality according to that.
> can't pretend to live in that alternate reality
Discussions about solutions that don't exist or requirements not implemented are everyday occurrences and necessary.
I mean, if you're talking with a contractor about how your bathroom should look, that is a "fictional alternate reality", but you're not pretending to be living in it now.
I don't understand the purpose of the above engagement style, but it doesn't look like a great fit for HackerNews.
For anything else, it depends on the exact scheme:
If git sent GPG the bits for the current commit specifically because it expects a better hash to be used, that would be silly to design on purpose (git should use a hash that meets all requirements). And it wouldn't protect history, which matters.
If git rounded up the bits of history, that would perform unacceptably badly.
If git used a better hash to secure history for signing purposes, and still had the normal hash elsewhere, that would be very silly to design on purpose because it should use the better hash for everything.