The Git 3.0 Hash Switch Nobody Is Ready For

Git 3.0 will default to SHA-256. The real cost isn't security — it's every regex, URL, and database column that assumes 40 hex characters.

Dafallah Ibrahim

— 2 min read
Share

Somewhere in your stack, a regex assumes a Git commit hash is exactly 40 hex characters. Git 3.0 is about to make that regex a lie: the upcoming release flips the default object format to SHA-256, and GitButler just published an argument that the switch is a costly mistake. Wherever you land on it, the breakage lands on you — not on Git.

The uncomfortable detail: SHA-256 repositories already work, and they've stayed a niche for one stubborn reason. A SHA-256 repo cannot push to, pull from, or share objects with a SHA-1 repo. The format is picked at init and it's permanent.

Why this matters

Commit hashes look internal. They aren't. They escape into GitHub URLs, issue tracker references, deploy tables with char(40) columns, CI cache keys, provenance attestations, and log parsers. Twenty years of tooling assumes the shape of a SHA-1 object ID.

Flip the default and every newly created repo is born incompatible with that ecosystem. Not slower, not degraded — structurally unable to exchange objects with most remotes it will ever meet.

How it works

None of this is new machinery. git init --object-format=sha256 has worked since Git 2.29, recording extensions.objectFormat in your config. Every blob, tree, and commit gets a 64-character ID instead of 40.

The missing piece was interoperability. The long-term plan included a transition layer where a repo could speak both formats; that never fully shipped. The only real migration is rewriting history with git filter-repo, which changes every commit hash anyone has ever referenced.

And the security payoff is smaller than it sounds. Git has shipped hardened SHA-1 with runtime collision detection since 2.13 — known collision techniques get caught as objects enter the repo. That's the core of GitButler's case: a large compatibility bill for replacing a hash that isn't practically broken in Git's threat model.

Where this helps

  • Deploy and audit pipelines. A char(40) column or fixed-length validator rejects the first 64-char SHA the day someone provisions a new-format repo.
  • Mirrors and backups. Secondary remotes, forks, and Gerrit-style servers must match the object format exactly. A SHA-256 repo can't mirror to a SHA-1 remote.
  • Signed releases. Any history rewrite invalidates signed tags plus every external commit link — changelogs, CVE references, release notes.
  • CI provenance. Attestation and SBOM tooling that parses digests with length assumptions fails quietly, then loudly.

Watch out

This is a default flip, not a forced migration. Existing repos don't convert themselves, and nothing breaks the morning after you upgrade. The real risk is drift: new repos silently diverging from your tooling.

Some compliance regimes genuinely require SHA-256. If that's you, adopt it deliberately — greenfield repo, matched server versions, no external references yet. Everyone else should grep for [0-9a-f]{40} before 3.0 lands, not after.

Try it yourself

Build a SHA-256 repo in a scratch directory and watch the assumptions fail:

mkdir hashlab && cd hashlab
git init --object-format=sha256 . >/dev/null
echo "still works" > README.md
git add . && git commit -qm "first"
git rev-parse HEAD
git rev-parse HEAD | grep -qE '^[0-9a-f]{40}$' \
  && echo "clean" || echo "your validators just broke"

TL;DR

  • Git 3.0 will make SHA-256 the default object format; GitButler argues the switch costs more than it protects.
  • Hashes leak into URLs, columns, regexes, and signatures — and SHA-256 repos can't exchange objects with SHA-1 ones.
  • Try git init --object-format=sha256 in a scratch repo today and audit everything that assumes 40 hex characters.

Read more