Scott Chacon’s post “Git 3.0’s upcoming SHA-256 default will be a costly mistake” went up on his Butler’s Log on October 1 and was sitting at 523 points and 481 comments on Hacker News by Thursday night. The claim is narrow: when Git 3.0 ships — the project has been aiming at late 2026 — a plain git init will produce a SHA-256 repository instead of a SHA-1 one, and every tool that assumes a 40-character hex string finds out in production.

Chacon’s case is that the hash was never the security boundary. SHA-1 is “good enough, fast enough” for generating unique keys inside a repository you already trust; the trust comes from the host and from signing keys. Hence: “We could be using MD5 and it would honestly probably be just fine.” He’s also right that the NIST 2030 deadline gets oversold — it governs SHA-1 used “for applying cryptographic protection,” not SHA-1 sitting anywhere in your stack, and OpenSSL 3 will hand an application a non-FIPS implementation of a hash even inside a FIPS module.

So one side of this fight is arguing badly. That is not the interesting part.

The Bill Isn’t Cryptographic. It’s That We Let a Hash Become a Name.

The migration is expensive because Git’s content address escaped the repository. A commit hash is a build cache key, a lockfile entry, a permalink someone pasted into a ticket in 2023, an artifact metadata field, a submodule pin, a line in an SBOM. None of those consumers know what a hash function is. They know they have a 40-character column in a database with a uniqueness constraint on it.

“We don’t have a hash column and a format column,” one platform engineer at a CI vendor put it in a Slack DM at 11:40 on a Tuesday night, mid-on-call. “We have a hash column.” That’s the entire migration, described as a schema.

The deploy tooling vendor DeployHQ noted in February that Git 2.48 through 2.51 had shipped the groundwork, and that the 3.0 timeline “depends largely on ecosystem readiness” — specifically how fast GitHub, GitLab and Bitbucket move. Sit with that. The release date of the world’s most widely deployed version control system is now hostage to three companies’ roadmap meetings, because the thing being changed isn’t an implementation detail of Git. It’s an identifier that a few million unrelated systems agreed, informally and without a spec, to treat as permanent.

Interoperability Covers the Easy Half

The reassuring line, repeated in nearly every summary of this transition, is that SHA-1 and SHA-256 repositories can interoperate, so nothing breaks overnight. True, and irrelevant to the expensive part. Git’s own hash-transition document is blunter: SHA-256 repositories cannot be read by older versions of Git. Submodules can’t mix formats. Converting an existing project breaks every existing signature and every SHA-1-based URL. The new gpgsig-sha256 field exists precisely because the old signature field was bound to the old hash.

Those aren’t edge cases. Signatures and URLs are the artifacts that leave the building — the ones auditors request and customers bookmark. Interop translates object IDs for Git’s plumbing. It does not un-break a signed release tag that another company’s compliance process already archived, or a permalink that a customer’s runbook still points at.

Chacon’s Fix Is Better Than His Framing

His alternative is to keep SHA-1 as the name and add an independently computed SHA-256 — or BLAKE3 — as a signed header on commits and tags. That decouples the identifier from the integrity claim, which is the correct instinct, and it satisfies the NIST reading by construction, since SHA-1 stops protecting anything.

But notice what accepting it requires. It means admitting that a content-addressable store with no versioning, no alias table and no deprecation mechanism was quietly handed a decade of external contracts. It means the fix is neither “SHA-1 is fine” nor “SHA-256 is mandatory” — it’s that we need a way to retire a name, and the ecosystem that produced Git has spent thirty years insisting that versioned interfaces are bureaucratic overhead.

That’s the uncomfortable part for anyone nodding along with Chacon. This migration is a mess not because a standards body overreached, but because the small-tools, no-central-authority, conventions-over-specs culture that made Git great is exactly the culture that cannot gracefully rename anything. The bill for that is arriving, and it’s payable in the one currency nobody in this argument wants to spend: coordination.

Sources