Git's proposed SHA-256 default draws a 'costly mistake' objection from GitHub's co-founder

Git's draft plan for version 3.0 would switch the default object format for newly created repositories from SHA-1 to SHA-256, and it has drawn a sharp public objection from one of the platform's founders. On October 1, Scott Chacon — co-founder of both GitHub and the Git client maker GitButler — called the plan a "costly mistake". According to a dev.to analysis of the proposal, the disagreement is not really about whether stronger hashing is desirable; it is about how much migration work the switch forces onto every tool and service built around Git's existing identifiers.

What the proposal actually changes

The Git 3.0 breaking-changes document proposes flipping the default from sha1 to sha256 for new repositories only, and ties the change to readiness across libraries, applications and hosting services. The dev.to write-up stresses two qualifiers that often get dropped from summaries: there is no planned release date, and no planned deprecation of SHA-1. Existing repositories keep their object format when the Git executable is upgraded, so nobody is forced to rewrite history on day one.

What the change does alter is a different decision: once the default flips, choosing an object format for a brand-new project becomes a more consequential call, because that choice now diverges from the installed base.

Why a new hash reaches the whole history

Git does not display hashes as decoration; it addresses objects by them. Blobs hold file contents, trees reference other objects, and commits point at trees and earlier commits — all by name. Change the algorithm and every object name changes, and because objects embed one another's names, the change propagates through the entire repository structure. Updating a label shown on a web page, as the dev.to article notes, would leave those underlying references unresolved.

A same-payload demonstration in the article produced a 40-character SHA-1 object name and a 64-character SHA-256 name for identical content — and both include Git's internal object framing, so they are not plain file checksums. Chacon's forecast of ecosystem pain targets exactly this surface: tools that hard-code 40-character identifiers, links pinned to object names, and signature handling. The official transition design includes mappings between SHA-1 and SHA-256 names, signature representations and staged compatibility, but those are design goals; a maintainer still needs an implementation that understands the relevant parts, and users need to know which version they actually run.

The security argument and the counter-proposal

The security case has a documented history. Git's own background material records the practical SHAttered collision of 2017, and Git 2.13.0 and later use hardened SHA-1 by default, which defends against that attack. The 2020 SHA-1 is a Shambles research went further, demonstrating chosen-prefix collisions and a PGP identity impersonation — though, as the dev.to author points out, it did not demonstrate a break of current hardened Git.

Chacon argues the ecosystem bill buys too little additional protection. He proposes separating object addressing from a strong tree-content hash that can be included in signed objects, pointing to a proof of concept and the existing git-evtag approach. He also leans on Linus Torvalds' 2005 remark that "The real security is in distribution". The dev.to author takes a measured view: Chacon's compatibility concern deserves a hearing, while both the protection hardened SHA-1 already provides and the case for resistance to future attacks deserve accurate statement. No independent performance comparison settles the choice between the official transition and the alternative.

What the compatibility checks showed

The article's own tests put evidence behind the concern. Using Git 2.34.1, a fetch from a SHA-1 fixture repository into a SHA-256 one exited with code 128 and the error "fatal: mismatched algorithms: client sha256; server sha1" — consistent with the git-init documentation's statement that there is presently no interoperability between the formats. The test measured a released Git version, not Git 3's eventual behaviour.

GitHub offered a narrower positive signal. A read-only ls-remote against maintainer Brian Carlson's public talk repository returned a 64-character HEAD, and slides at that exact revision state that SHA-256 is now in private preview — with repository creation still unavailable publicly. No writes, ordinary project creation or integration compatibility were tested, so the result says nothing about general availability.

Why it matters

This is not an emergency, but it is a planning signal for anyone who hosts, wraps or scripts Git. A default change at the Git level becomes a support question at every layer above it: repository hosts are only beginning to serve SHA-256 repositories, CI integrations embed their own Git libraries, and internal tooling may carry fixed-width assumptions about object names. A script that accepts longer identifiers and a parser with a hard-coded length face very different jobs.

The practical advice from the dev.to piece is to test now with disposable projects: pick the real path a commit takes through your organisation, check which Git implementation each stage uses, and audit for fixed-length identifier assumptions and stored or linked object names. Changing one regular expression will not answer every compatibility question — and the earlier teams map their exposure, the cheaper the eventual migration, whichever design wins the argument.