But that is a less disruptive change, because it's managed in headers; it's not part of the core of how objects are linked together.
You just have new header fields (or values for existing fields) which indicate that this is such and such a new style signature, and that's mostly it. Older git won't validate it or produce it. Newer git validates and produces old and new.
Importantly, older git installations will be able to read the commits, etc, just not validate the signatures.
This is not to avoid replacing the compromised hash function as such (taking away the choice from people making new git projects). We have that already.
But existing repos aren't based on that new function. Not everyone wants to switch their existing repos to to start using SHA-256; that means the repos don't work with older git.
You just have new header fields (or values for existing fields) which indicate that this is such and such a new style signature, and that's mostly it. Older git won't validate it or produce it. Newer git validates and produces old and new.
Importantly, older git installations will be able to read the commits, etc, just not validate the signatures.
This is not to avoid replacing the compromised hash function as such (taking away the choice from people making new git projects). We have that already.
But existing repos aren't based on that new function. Not everyone wants to switch their existing repos to to start using SHA-256; that means the repos don't work with older git.
The disruption is real.