[AgentME]

SHA1 was already found to be weak when git was made. Linus would have done better to use a strong hashing algorithm to begin with than to try to incorporate cryptographic agility. It was only found to be weak a few months before git's release though.

Regardless, I think cryptographic agility makes a lot more sense for a storage format like git than it does for a wire format. A shared repo being upgraded from gitv1 to an incompatible gitv2 would need everyone to switch versions at once. With WireGuard, a server could offer support for both v1 and v2 clients, then both v1 and v2 clients can connect to it at the same time, and clients can upgrade on their own schedule. The protocol doesn't have to make any special allowances, like making any data structures interpretable by both, besides to have both v1 and v2 on different ports or have different initial connection messages.

WireGuard was developed in response to protocols like IPSec, OpenVPN, and TLS, which emphasized configurability and cryptographic agility to a fault. Not only were they hard to use and easy to misconfigure, but each one of them were at times vulnerable to downgrade attacks because of subtle bugs in their ability to be configured. It's better to be able to have few code paths and verify they all work as expected, than it is to have many code paths, only verify the happy path, and hope that there's no way for users to fall down an unstudied insecure path by their own fault or because of attackers.

[tptacek]

Doesn't agility make even less sense in a file format? Browsers, for instance, don't need format agility to tell a PNG from a JPG. Meanwhile, PDF tried to provide exactly that capability, and it is a world-historic security disaster. The cryptographic equivalent is PGP, and... I rest my case.

[AgentME]

In git's case, by cryptographic agility I was imagining a Gitv2 which would produce SHA-256 hashes by default on new commits, and was able to still understand SHA-1 hashes on old commits so it could continue to read data produced by Gitv1 clients or Gitv2 clients in SHA-1 mode without needing an upfront convert-the-whole-repo step. Definitely less preferable than the alternative of just supporting SHA-256 from the very start though. May be less preferable to making git auto-convert repos forward to a new SHA-256-only version.

[hncensorsnonpc]

In his "L.T. on git" talk at google Torvalds said he used SHA1 not for security, that that would be elsewhere but he called sha1 the best (I think even most secure) hash out there. The serious most well know sha1 flaw was not discovered at that time AFAIK so not sure what you mean by already known as weak. And the fact that 3 years later git has not been broken proves its security does not rely on sha1 alone. I did not even know they are working on a change but good and makes sense of course.