Git 3.0's SHA-256 default: a costly, low-value migration
Original: Git 3.0's upcoming SHA-256 default will be a costly mistake
Why This Matters
A default hash change in Git touches every developer tool, host, and workflow on earth — compatibility breaks at scale.
GitButler co-founder Scott Chacon argues that Git 3.0's plan to make SHA-256 the default hashing algorithm will trigger an enormously expensive global migration for nearly zero practical security gain, warning that almost no one in the developer community is aware of what is coming.
Git has used SHA-1 as its content-addressing hash since Linus Torvalds created it in 2005. The algorithm underpins every object in every repository ever created — commits, trees, and file blobs — and accidental collisions have never been observed across billions of repositories. The birthday bound for SHA-1's 160-bit output would require roughly 1.4 septillion files in a single project to collide by chance.
SHA-1 is technically 'broken' in the cryptographic sense: published attacks (SHAttered in 2017, SHA-1 is a Shambles in 2020) showed that intentional collisions are theoretically achievable with enough GPUs and money. In response, Git's upcoming 3.0 release is planned to switch the default hashing algorithm to SHA-256.
Chacon's objection is not that SHA-256 is wrong — it's that making it the default breaks compatibility across every existing tool, host, and repository simultaneously, at enormous industry-wide cost. SHA-1 and SHA-256 repositories cannot interoperate natively. Every forge (GitHub, GitLab, Bitbucket), every CI system, every Git wrapper, and every internal toolchain would need updating before the transition could safely happen. He argues the actual threat from SHA-1 collision attacks against Git is negligible in practice, making the migration's cost-to-benefit ratio deeply unfavorable. Chacon says he has held back this critique for years but feels the release is approaching fast enough that the community needs the warning now.