SHA-256 Is Faster Than MD5 — So Why Is Git 3.0 Controversial?

Two Different Files, One Identical Fingerprint

In February 2017, Google's security researchers published a paper alongside two PDF files. Download both, open them, and you see different content. Feed them to SHA-1, the fingerprinting algorithm baked into Git since Linus Torvalds wrote the first lines of it in 2005, and you get the exact same string back. Not similar. Identical. A thing that was supposed to be, for all practical purposes, impossible.

That attack was called SHAttered, and it was not a surprise to cryptographers so much as a formal burial. SHA-1 had been showing cracks since the SHAppening in 2015, and Shambles in 2020 pushed the coffin deeper. The theoretical had become demonstrated, then cheap, then embarrassing. NIST had read the writing on the wall back in 2011 and deprecated SHA-1; it is now outright prohibited in FIPS 140-2 certified environments, which is the security standard that governments and serious enterprises are required to use.

Here is the strange part: none of that actually broke Git in practice. Git uses SHA-1 for data integrity, not authentication. But "hasn't broken yet" is an uncomfortable sentence to put in a compliance document, and regulators do not accept it as an argument. The pressure to move was real, and it was structural.

The replacement, SHA-256, produces a 256-bit fingerprint compared to SHA-1's 160 bits. It is a fundamentally harder mathematical problem to crack. And by 2026, benchmarks show it running four times faster than MD5, an older algorithm it has long since left behind. The case on paper is easy. The case in practice is where things get genuinely complicated.

How Git Learned to Trust a Number

When Linus Torvalds built Git in 2005, he reached for SHA-1 not because he was building a vault but because he needed a reliable label. The distinction matters. A hash, in Git's original design, was an integrity check — a way to confirm that the file you fetched was the file you sent, not a lock protecting treasure from adversaries. SHA-1 was fast, short, and practically collision-free for honest data. That was enough, then.

The mechanism Git built around that label is called content-addressable storage. Every object Git tracks — a file's contents, a directory snapshot, a commit — gets named by its own hash. Nothing is stored by path or date or author. You find a commit the same way you find a word in a dictionary: by its name, which is derived directly from its contents. Change one byte in a file, and the hash changes, which changes the commit, which changes every subsequent entry in the chain. The history is the hash.

This is elegant, and it is also the reason the SHA-256 upgrade is so structurally disruptive. A SHA-256 hash produces 64 hexadecimal characters; SHA-1 produces 40. That 60-percent growth in fingerprint length is not just a storage detail — it is baked into every script, every API response, every regex pattern anyone has ever written that expects a 40-character string. Git has offered SHA-256 as an opt-in experiment since version 2.29, released in 2020. Git 3.0 does not add a new option — it changes the default for every new repository created with git init. That is a different kind of move entirely.

What Git 3.0 Actually Changes — and What It Quietly Removes

The Git 3.0 SHA-256 migration does one thing loudly and several things quietly. The loud part: every new repository created with git init will default to SHA-256, producing 64-character hex identifiers instead of the 40-character strings that have been the pulse of version control for two decades. The quiet part is a tidy list of removals.

Seven legacy commands are being dropped. The default branch name officially moves from master to main, a change that has been optional since 2020 and is now simply the rule. Reftable storage replaces the old flat-file reference format — a practical necessity, since storing and traversing 256-bit hashes at the scale of modern repositories demands something more efficient than the format Git inherited from 2005.

One change will surprise developers who compile from source: building Git 3.0 now requires a Rust toolchain. That is not just a dependency addition. It is a signal about where the project's infrastructure is heading — the same gradual shift happening across the Linux kernel, the Android platform, and a growing list of systems software.

The reftable change deserves a moment. Think of the old reference format as a filing cabinet where every branch name maps to a commit hash on a separate slip of paper. It worked at 2005 scale. At the scale of a monorepo with thousands of branches and 64-character hashes throughout, it becomes a slow shuffle through a very large drawer. Reftable replaces the drawer with an indexed ledger designed for the new arithmetic.

None of these changes are secret. All of them, taken together, add up to something that will land differently depending on where you sit in the ecosystem.

Two Worlds That Cannot Speak to Each Other

Picture two archivists working in the same building, one cataloguing every document with a 40-character code, the other with a 64-character one. Hand a file from one desk to the other and both systems stall. Neither catalogue entry matches. This is not a metaphor that breaks under scrutiny — it is almost precisely what happens when a SHA-256 repository tries to push to or pull from a SHA-1 repository. The object names simply do not correspond.

Git does provide a narrow bridge. Index files support a bidirectional mapping between SHA-1 and SHA-256 object names, so in theory a translation layer can exist between the two worlds. But "in theory" is doing heavy lifting in that sentence. The mapping is partial, the edge cases are still being catalogued, and developers working at the intersection of both formats are, in effect, the people discovering where the bridge runs out.

The hosting landscape makes the practical situation starker. GitLab added experimental SHA-256 repository support in version 17.3, released in August 2024 — a real step, even if the word "experimental" signals that not everything is load-bearing yet. GitHub and Bitbucket have not yet offered full general support. That leaves the two largest platforms in the world still operating exclusively in SHA-1.

What this produces is not a clean cutover but a fracture running through the entire toolchain. A team that adopts SHA-256 today faces a multi-year period where submodules pointing at SHA-1 projects, cross-project pull requests, and CI pipelines must simultaneously speak both dialects. Scripts that assume a hash is always 40 characters will simply break. The translation layer narrows the gap; it does not close it. How long that gap stays open is, at this moment, genuinely unknown.

The security argument is the banner; the regulatory requirement is the engine.

The Case Against: When the Cure Costs More Than the Disease

Scott Chacon helped build GitHub. He knows the plumbing better than almost anyone alive. And his verdict on the SHA-256 default is not gentle: he has called it a costly mistake that delivers little practical security benefit for most users. That is not a fringe opinion from someone who missed the memo on SHAttered. It is a considered argument from someone who has watched the ecosystem grow for two decades and is now watching it prepare to saw off a structural beam.

His core point deserves a fair hearing. For the vast majority of developers, the actual threat from a SHA-1 collision in a Git repository is close to theoretical. The real pressure driving the hash algorithm switch is not a hacker in a basement; it is a compliance officer with a checklist. FIPS 140-2, the US government's security standard for cryptographic modules, prohibits SHA-1 entirely. Enterprise and government customers need that certification.

Meanwhile, the collateral damage is concrete. Thousands of internal scripts and CI/CD pipelines contain regex patterns that match exactly 40 characters — they will not warn you when they break. They will simply produce wrong answers, or nothing at all, in ways that may take months to notice. The signed-header approach, a proposed alternative, would have grafted a security layer onto the existing object format without touching the hash length at all — same addresses, new armour. Its advocates call it the road not taken. Whether they are right, or whether they are simply underestimating the long-term cost of staying on SHA-1, is a question the community has not finished arguing.

The Questions Nobody Has Answered Yet

No confirmed release date exists for Git 3.0's general availability. The tentative window is late 2026, but "tentative" is doing real work in that sentence. Nobody has announced an official bridge tool for migrating the world's existing SHA-1 repositories either, which means the transition plan currently has a large, conspicuous gap at its centre.

GitHub's position is harder to parse than GitLab's. GitLab 17.3 enabled SHA-256 repository support experimentally in August 2024. GitHub has not published a timeline for moving past its own research phase. Bitbucket's status remains similarly unresolved — meaning the three platforms holding the majority of the world's code may not all be ready when the default flips.

The performance question is equally open. SHA-256 hashes run to 64 characters against SHA-1's 40, and every operation Git performs touches those identifiers. The real-world cost in CPU cycles and memory, measured across repositories of genuine industrial scale, has not been comprehensively published. Four times faster than MD5 is a benchmark that tells you almost nothing about what happens when a CI/CD pipeline starts hashing billions of objects per day.

Every version of every project ever committed to Git is stored in a system whose fundamental identifier is about to change. The Git 3.0 SHA-256 dilemma is not resolved by flipping a default — it is just beginning. The shape of that change is still being drawn. The notebook entry for this one stays open.