I posted this on the reddit thread, but I thought it would be interesting to hear feedback here too:

I don't know much about git internals, so forgive me if that is a bad idea, but what does everyone think about it working like this:

If future versions of git were updated to support multiple hash functions with the 'old legacy default' being sha1. In this mode of operation you could add or remove active hashes through a configuration, so that you could perform any integrity checks using possibly more than one hash at the same time (sha1 and sha256). If the performance gets bad, you could turn off the one that you didn't care about.

This way by the time the same problem rolls around with the next hash function being weakened, someone will probably have already added support for various new hash functions. Once old hash functions become outdated you can just remove them from your config like you would remove insecure hash functions from HTTPS configurations or ssh config files. Also, you could namespace commit hashes with sha1 beging the default:

git checkout sha256:7f83b1657ff1fc53b92dc18148a1d...

git checkout sha512:861844d6704e8573fec34d967e20bcfef3...

Enabling/disabling active hash functions would probably an expensive operation, but you wouldn't be doing it every day so it probably wouldn't be a huge problem.

Take a look at multihash[0]. I don't know the inner workings of the program, but I imagine it would be possible for `multihash` to periodically rehash files (as a cron job?) when a new crypto algorithm gets introduced.

[0]: https://github.com/multiformats/multihash