That's not good enough though if you need to work with repositories that were made with previous releases. Just converting them is one thing, but what if you need to stay compatible indefinitely.
And what about old releases that encounter a new repo?
And what about URLs and emails that reference commit hashes? Think archives of mailing lists that suddenly become useless unless there's a way to keep both hashes around.
Yes. These are all solvable problems (maybe not the old-release needing to handle new-style repo gracefully), but the complexity is much higher than upgrading a global constant.
I think you could solve most problems by just enabling a different hash function with no backwards compatibility. Repositories have a format-version somewhere, and migrating from git to git-with-new-hash should be a fairly simple operation. You can always edit commit messages to add "corresponds to commit <sha1> in <old repo>". This is of course not as nice as full backwards compatibility, but it gets rid of the security problem for relatively cheap.
And what about old releases that encounter a new repo?
And what about URLs and emails that reference commit hashes? Think archives of mailing lists that suddenly become useless unless there's a way to keep both hashes around.
Yes. These are all solvable problems (maybe not the old-release needing to handle new-style repo gracefully), but the complexity is much higher than upgrading a global constant.