This is a justification that was made up after Git came under increasing criticism for its poor choise of a hash function after the shattered attack. It was already known that SHA-1 is weak before Git was invented.
The problem is... it doesn't line up with the facts.
Git has been using SHA-1 hashes for signatures since very early on. It also has claims in its documentation about "cryptographic security". It does not rigorously define what "cryptographic security" means, but plausibly, it should mean using a secure hash function without known weaknesses.
"So that was one of the issues. But one of the issues really was, I knew I needed it to be distributed, but it needed to be really, really stable. And people kind of think that using the SHA-1 hashes was a huge mistake. But to me, SHA-1 hashes were never about the security. It was about finding corruption.
Because we’d actually had some of that during the BitKeeper things, where BitKeeper used CRCs and MD5s, right, but didn’t use it for everything. So one of the early designs for me was absolutely everything was protected by a really good hash."
That's a valid point. However, modern hardware and crypto algorithms are fast enough that it pays off to have "do it all" protocols, with as little tradeoffs as possible.
Example: Git users do need both corruption protection AND secure authentication. If authentication is not built in, it will have to be built around. Building around is always going to be more costly in the end.
Unfortunately, 20-30 years ago considerations such as "sha1 is shorter + faster" were taken seriously, plus all the crypto that existed back then sucked big time. Remember Snowden scandal in 2013? That, plus Bitcoin and blockchains moving towards mainstream brought about review of TLS, started SHA-3 competition. Many more brains turned to crypto since then and the new era began.
If this were true, then wouldn't MD5 have been the better choice?
Also, SHA-1's preimage resistance (which still isn't broken) is necessary for the security of signed commits, regardless of the hash function used for the signature itself, since a commit object references its tree and predecessor commit by their SHA-1 hashes.
The problem is... it doesn't line up with the facts.
Git has been using SHA-1 hashes for signatures since very early on. It also has claims in its documentation about "cryptographic security". It does not rigorously define what "cryptographic security" means, but plausibly, it should mean using a secure hash function without known weaknesses.