Scott Chacon says Git 3.0's SHA-256 default will cost the industry a lot of time for little real security gain

Opening a terminal and typing git init on Git 3.0 will create a repository that cannot push to a server expecting SHA-1 and cannot share submodules with any project created before the switch. Scott Chacon, co-founder of GitHub and now of GitButler, published a 17-minute case this morning that the whole migration is about to cost the industry a lot of time for little gain, and the post has 156 Hacker News points in a few hours.

Git 3.0 will change its default content hashing algorithm from SHA-1 to SHA-256. The change is a response to published SHA-1 collision attacks (SHAttered in 2017, SHA-1 is a Shambles in 2020). Chacon argues those attacks are not how real repository compromises happen, so the migration will cost a lot without reducing real risk.

Why Chacon says the risk is theoretical

Hash functions can be broken in two ways. A collision attack means an attacker generates two files with the same hash on purpose, hands over the benign one, then swaps in the malicious one later. A second-preimage attack means an attacker takes a file somebody else wrote and forges a different file with the same hash. The second one is far more dangerous, and Chacon argues no widely used hash function is realistically open to it.

So any realistic SHA-1 attack rests on a collision, which means the original author of the file is also the attacker. In the real world the cheaper path to malicious code is to socially engineer the maintainer of a popular npm package or buy out an unpaid open-source project for a lump sum. "Git could be using MD5," Chacon writes, "and it would honestly probably be just fine," because trust in Git is about where you pull from, not about the hash.

What the migration will cost

The cost shows up as interoperability failures. New SHA-256 repositories cannot push to a server that was created as SHA-1, and the server has to be told which type it is at creation time. Submodules only work between projects of the same hash, so a library used by both an old project and a new one needs two versions. Hosting providers may run mirror copies in each format, but every operation on every repository then costs twice.

Converting an existing project is harder. Every object in the project (every commit, tree and blob) gets a new ID, which breaks every existing signature, every tag that signed a release, and every tool that stored a commit SHA. Everyone working on the project has to cut over at the same moment or end up with a split history.

Chacon cites a recent talk by Emily Shaffer on how Google is preparing for the migration and describes the project as a large and painful one.

For a team on Git today, the practical thing is to know which object format a new repository picked. git init --object-format=sha256 creates a SHA-256 repository on current Git, and the Git 3.0 default will do it without the flag. A repository in the wrong format cannot be pushed to a server that only takes the other one. Deferring the decision is still possible by staying on Git 2 until hosts, CI systems and dependencies agree on how both formats coexist.

Source

• Primary source: Scott Chacon, GitButler blog: Git 3.0's upcoming SHA-256 default will be a costly mistake, 1 October 2026
• Discussion: Hacker News thread, 1 October 2026