Posted on Oct 2

Git SHA-256 migration: what the Git 3 proposal actually changes

#git #github #versioncontrol #sveltekit

Git's proposed SHA-256 default has prompted a fight over how much migration work stronger hashing should require. On October 1, GitHub and GitButler co-founder Scott Chacon called the plan a "costly mistake". For developers, the immediate question is whether a new repository format will work through the tools they already depend on.

TL;DR

Git's official proposal changes the default for new repositories, requires ecosystem readiness and gives no release date. SHA-1 support remains.
Our local Git 2.34.1 fetch test rejected mixed object formats. That demonstrates a current compatibility boundary; Git 3 was never under test.
Modern Git uses hardened SHA-1 against known collision attacks. Chacon proposes a separate strong tree-content hash, an alternative the project has not adopted.
One public GitHub preview repository returned a SHA-256 object name in our read-only check. General creation and write support remain outside what we verified.

What the Git SHA-256 proposal changes

The Git 3.0 breaking-changes document proposes switching the object-format default from sha1 to sha256 for newly created repositories. It ties the change to readiness across libraries, applications and hosting services. That qualification belongs in every summary of this story.

The document also says there is no planned release date and no planned SHA-1 deprecation. An existing repository keeps its object format when you upgrade the Git executable. Your team's next planning meeting can survive without an emergency hash-migration ticket.

The disagreement concerns the future default and the work needed to support it. Chacon argues that the cost reaches far beyond Git itself, into tools built around its existing object identifiers. His background gives him experience with that tooling, and GitButler is also a Git-tools business. The argument still needs checking against the official plan and implementation evidence.

I'd separate two decisions: upgrading Git, and choosing an object format for a new project. The proposal makes the second decision more consequential once the default changes. It supplies no deadline for converting a team's existing history, and it leaves SHA-1 available.

Why changing object names reaches the history

Git's hash-transition design explains why this change runs deeper than making a displayed checksum longer. Git addresses objects by hashes. File contents become blobs, trees reference other objects, and commits refer to trees and earlier commits.

Change the hash algorithm and those object names change. References inside other objects also need the corresponding names, so the change propagates through a repository's history. A tree or commit participates in that structure; updating the label shown in a web page would leave the underlying references unresolved.

In our same-payload demonstration, the text The Daily Diff followed by a newline produced a 40-character SHA-1 object name and a 64-character SHA-256 object name. Those are hashes of Git's blob encoding. They include Git's object framing, so treating them as plain-file checksums would misdescribe the demonstration.

Chacon forecasts migration work for tools that hard-code 40-character names, links tied to object identifiers and signature handling. Which individual integrations fail depends on their implementation. A script that accepts longer identifiers and a parser with a fixed-width assumption can face very different jobs.

The official design includes mappings between SHA-1 and SHA-256 names, along with signature representations and staged compatibility. These are design goals. A tool maintainer still needs an implementation that understands the relevant parts, and users need to know which version they actually have.

SHA-1 collisions and Chacon's alternative

The security concern has a documented history. Git's background section records the practical SHAttered collision from 2017 and explains that Git 2.13.0 and later use hardened SHA-1 by default. That hardening protects against SHAttered; the maintainers also want stronger hashing against future attacks.

The independent SHA-1 is a Shambles research went further in 2020, demonstrating chosen-prefix collisions and a PGP identity impersonation. That gives the security debate an actual result to discuss. Its demonstrated target was hash-based PGP identity material. A claim that it broke current hardened Git would require evidence this research does not supply.

Chacon thinks the ecosystem bill buys too little additional protection. He argues for separating object addressing from a strong tree-content hash that can be included in signed objects. His article points to his proof of concept and the existing git-evtag approach. This remains Chacon's proposed alternative. Git's official plan describes the SHA-256 transition.

He also cites Linus Torvalds' 2005 message, which says, "The real security is in distribution." Linus created Git and chose SHA-1 then. That historical view helps explain Chacon's position. Today's default proposal belongs to the Git project, and the security evidence accumulated after that message matters too.

I think Chacon's compatibility concern deserves a hearing. I also want the hardened-SHA-1 protection and the case for future attack resistance stated accurately. We have no independent performance comparison here that settles the choice between the official transition and his alternative.

What our compatibility checks actually showed

Our local demonstration used Git 2.34.1 and isolated temporary bare repositories. After populating the SHA-1 fixture with a commit, we attempted to fetch from it into a SHA-256 repository. Git exited with code 128 and this exact error, recorded in the episode's evidence/compatibility.json:

fatal: mismatched algorithms: client sha256; server sha1

That agrees with the current git-init documentation, which says there is presently no interoperability between the formats. The test reaches format negotiation and demonstrates the boundary in our installed version. It measures neither Git 3's eventual behavior nor migration performance.

GitHub supplied a more interesting wrinkle. We ran this read-only command against Brian Carlson's public talk repository:

git ls-remote https://github.com/bk2204/talk-rust-in-git.git HEAD

The returned HEAD was 64 hexadecimal characters long. Carlson's slides at that exact revision say "SHA-256 now in private preview". The same slide says repository creation is still coming and remains unavailable publicly.

So GitHub can serve this preview repository. That is useful progress, with a narrow scope. We tested no writes, ordinary project creation or integration compatibility, and the result provides no general-availability guarantee. The community discussion supplies the public context for the preview.

How I'd prepare a Git migration test

For a team considering SHA-256 repositories, I'd start with a disposable project and the actual path a change takes through the organization. Which Git implementation does the editor use? Which library does the CI integration embed? Can the chosen host support the intended operations for the account you have?

I'd treat those as questions to test. A successful read from a preview repository answers one of them. Creating a repository, pushing a change and consuming it through another tool are separate operations that need their own evidence.

For internal scripts, I'd look for fixed-length assumptions about object names, then check systems that store or link to those identifiers. Where signatures matter, I'd compare the integration's support with the transition design's mapping and signature goals. Changing a regular expression alone won't answer every compatibility question.

My output would be a small record of tool versions, tested operations and observed failures. That is more useful to the next maintainer than "works on my machine," the traditional distribution format for future incidents.

Existing teams can keep their current repository format while assessing that chain. The proposed default explicitly depends on the ecosystem being ready. Checking the tools hiding behind a friendly UI is part of finding out what "ready" means for your team.

Also in this episode: Pi 1.0 and SvelteKit 3

Pi 1.0 is Earendil's minimal, extensible coding-agent harness, released October 1 with native MCP support through Codemode and deferred tool loading. Pi Durable is a separate experimental package for checkpointed tasks, with memory, SQLite and JSONL backends. After a crash, an interrupted tool reruns only if it declares replay safe; otherwise the interruption is reported to the model. I'd check that declaration carefully for any tool with external effects, because crash recovery gives no blanket exactly-once guarantee.

SvelteKit 3 also arrived October 1, moving configuration into vite.config.ts and replacing $lib with #lib through standard subpath imports. The migration guide supplies a codemod that automates what it can and leaves TODOs for the rest. Remote functions still require experimental Async Svelte. I'd budget time to read the remaining diff and check the maturity of features the application actually uses.

Verdict: NEEDS REVIEW

I stamped this episode NEEDS REVIEW. I'd keep the stronger hash option and test the whole toolchain before changing defaults. Compatibility is part of shipping the security improvement.

The official proposal already acknowledges ecosystem readiness, and the GitHub preview shows real work toward it. Chacon's objection is worth evaluating against that work. I'd want operation-by-operation results before making a recommendation for a team's new repositories; the local mismatch and one successful remote read leave plenty to check.

FAQ

When will Git 3.0 switch to SHA-256?

The official proposal gives no planned release date. The new-repository default is conditional on readiness across libraries, applications and hosting services.

Will Git 3.0 convert existing SHA-1 repositories?

The proposed default covers new repositories. Upgrading the executable does not automatically change an existing repository's object format, and no SHA-1 deprecation is planned.

Does GitHub support SHA-256 repositories?

Our read-only check verified one public preview repository. Carlson's slides describe private preview support and say repository creation is coming. This check establishes no general creation or write guarantee.

Does a SHA-1 collision mean modern Git is broken?

Git uses hardened SHA-1 against known collision attacks. The cited chosen-prefix research demonstrated a PGP identity attack. It did not demonstrate a break of current hardened Git; Git's maintainers also seek stronger protection against future attacks.

Sources

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

DEV Community