Git 3.0’s SHA-256 default draws fire: the GitHub compatibility gap

Git 3.0 plans to default new repositories to the SHA-256 object format (testable today via git init –object-format=sha256). Scott Chacon — co-founder of both GitHub and GitButler, author of Pro Git — published a rebuttal calling the migration “an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.”

The facts

• The change: new repos default to SHA-256 object hashes in Git 3.0.
• Chacon’s argument: SHA-1’s real-world threat to Git is collision attacks (forging new commits), not second-preimage attacks (rewriting existing ones); “the real security is in distribution” — he quotes Linus from 2005.
• The alternative: independent tree-hash headers dual-signing SHA-1 plus SHA-256/BLAKE3 (after git-evtag); his PoC hashes Chromium’s 35GB, 2.1M-file tree in 5 seconds (github.com/schacon/tree-sha256).
• The key fact: GitHub does not yet support pushing SHA-256 repos — “the main thing currently delaying 3.0,” per Chacon.
• The clock: NIST requires SHA-1 deprecation by 2030.

What the migration actually costs

An object-format change means every hosting platform, CI system and local hook needs dual-format compatibility — the Git community has discussed this migration for eight years without landing it. GitHub’s support schedule is the de facto gate.

Is the dual-hash route sound?

Chacon’s proposal is “sign on top, don’t touch the foundation”: keep SHA-1 compatibility and add tree-level SHA-256/BLAKE3 headers for tamper evidence. Critics will note it leaves the SHA-1 collision surface open (an attacker can still craft two identical-SHA-1 commit objects — just with different tree headers); supporters argue distribution checks close the practical gap. It is the classic trade between cryptographic correctness and operational cost.

The infrastructure-governance echo

The same week brought arXiv’s submission caps and Cloudflare’s K2 streams: three instances of one question — who changes the defaults of global infrastructure, and at what cadence.

Editorial take

For working developers the 2026 advice is unchanged: enable push verification and commit signing on important repos, and follow your platform’s default-format migration when it ships. The real value of this fight is that it stages the tension between “cryptographically correct” and “operationally feasible” in public — for infrastructure as globally embedded as Git, any default change is a decade-long affair.

The counter-arguments, stated fairly

The pro-SHA-256 side has a real case: SHA-1 has practical collision attacks since 2017 (SHAttered), NIST’s 2030 deadline is close, and “dual-hash headers” leave collision-forged commits inside the object database even if tree headers catch them at checkout. Security researchers have wanted this default for years. What Chacon adds to the debate is an operational accounting — the platform-compatibility matrix and a cheaper alternative — that the Git maintainers’ roadmap has so far not addressed in public.

What it means for platform operators

Hosts smaller than GitHub face the same gap with fewer resources: GitLab and Forgejo’s SHA-256 support trails the format change, and corporate Gitea instances are further behind. The realistic migration sequencing is: platforms ship push support first, Git flips the default second — and if the current disagreement holds, third comes either a dual-format transition period or the fragmentation Chacon warns about. Teams running self-hosted Git should file SHA-256 support requests now, not after 3.0 ships. Defaults are infrastructure policy; this one gets a decade of scrutiny.

The historical rhyme

This is the second time Git’s hash transition has stalled on ecosystem readiness rather than cryptography — the original SHA-256 plan dates to 2017, stalled on exactly this platform-support problem, and the intervening years added signing infrastructure (gpgsig, SSH keys, Sigstore) that makes Chacon’s tree-header approach more plausible than it was in 2018. The debate is real either way: two credible paths, one deadline, and a platform whose support schedule decides for everyone. The tree-header PoC hashing 35GB in five seconds is the argument’s strongest artifact.