Git 3.0 Will Default to SHA-256. Scott Chacon Says the Migration Costs More Than It Protects

Git 3.0 will create new repositories with SHA-256 instead of SHA-1, and GitButler co-founder Scott Chacon has published a 17-minute argument that the change will be "incomprehensibly expensive and ultimately valueless". Git's own documentation does not set a release date for 3.0.

The case for the change is in Git's BreakingChanges document. The case against is in Chacon's post on the GitButler blog. The two disagree on one factual point, covered below. A related infrastructure change is IANA's rework of the example.com page, which also breaks assumptions in old scripts. Another reimplementation-versus-original question is raised by OpenDLSS-NR.

What the Git project has committed to for 3.0

The document lists five breaking changes. The one at issue reads: "The default hash function for new repositories will be changed from "sha1" to "sha256"." It adds that "There is no plan to deprecate the "sha1" object format at this point in time."

Change in Git 3.0	What the document says
Default hash	New repositories move from sha1 to sha256
Rust	Optional in Git 2.52, default-on in 2.55, mandatory in 3.0
Ref storage	Default moves from files to reftable once the ecosystem is ready
Branch name	Default branch in new repositories becomes main
Bare repositories	safe.bareRepository default changes from all to explicit

The rationale cites NIST deprecating SHA-1 in 2011 and four attacks: SHAppening in 2015, SHAttered in 2017, Birthday-Near-Collision in 2019 and Shambles in 2020. On Rust, the document leaves room to move: "If we see that the impact on downstream distributions would be significant, we may decide to defer this change to a subsequent minor release."

Chacon's argument in 2 parts

The first part is about risk. SHA-1 produces 160 bits, and Chacon writes that an accidental collision would need roughly 1.4 septillion random files in one project. He concedes SHA-1 is "semi-broken" by the 2017 and 2020 attacks but says they are collision attacks, not second-preimage attacks, and that real compromises come from stolen credentials and bribed maintainers. He quotes Linus Torvalds, from 2005: "The real security is in distribution."

The second part is about cost. He lists 40-character hash assumptions in scripts, links that embed SHA-1 hashes, signatures that break on conversion, and libraries including git2, libgit2 and JGit that he says lack full SHA-256 support. He also writes that submodules only work between repositories of the same hash format.

The factual disagreement

Chacon says a repository created with SHA-256 cannot push to SHA-1 hosting. Git's hash-function transition document states the opposite as a goal: "A SHA-256 repository can communicate with SHA-1 Git servers (push/fetch)", with a bidirectional mapping table stored alongside the packfile.

Both can be true. A design goal is not a shipped, tested feature, and the document does not say how much of it is built. It does say plainly that "SHA-256 repositories cannot be read by older versions of Git". The document does not mention Git 3.0 or any default at all.

The alternative and its numbers

Chacon proposes computing an independent SHA-256 or BLAKE3 hash of the full tree and storing it as a signed header, next to the SHA-1 object name. He notes Colin Walters' git-evtag has done something close with SHA-512 tree checksums since 2015.

His cost figures are self-reported. He gives them for hashing a whole tree.

Repository	Size	Time to hash tree
Git project	not stated	17 ms
Linux tree	1.5 GB	257 ms
Chromium	35 GB, 2.1M files	5 seconds

He ties this to a NIST 2030 deadline, which he reads as applying to "applying cryptographic protection" and not to storage. That reading is his, and the Git documents do not address it.

Who pays on day one

The default applies to new repositories only. A team with existing SHA-1 history is not forced to convert, because the document sets no plan to deprecate the sha1 format. The people who meet the change first are those who run git init in a script, on a laptop with a newer Git, and then try to push to a host or a CI tool that expects 40-character names.

That is also where Chacon's complaint about confusing user experience lands: the hash is chosen at repository creation, so the mistake is made once and carried for the life of the repository. The same new-repository rule covers the other defaults in the table above. A script that assumes a branch called master, or a files-based ref directory, hits the same wall on the same day.

Distributors have a separate problem. The Rust milestone moves from default-on in Git 2.55 to mandatory in 3.0, which matters to anyone packaging Git for a platform where Rust is not already a build dependency.

What would settle it

Chacon's alternative is a proposal, and none of the three sources describes a released Git that implements it. Git's project has the opposite gap: a transition plan with modes called dark launch, early transition, late transition and post-transition, and no date given for any of them.

The test to watch is the hosting forges. If a SHA-256 repository can push to and fetch from a SHA-1 server in a released Git before 3.0 ships, Chacon's first cost item weakens. If it cannot, the default will meet his objection on day one.