DEV Community

Cover image for Git 3.0 Moves New Repos to SHA-256: What to Check Before It Ships
Moksh Gupta
Moksh Gupta

Posted on Originally published at devtoollab.com

Git 3.0 Moves New Repos to SHA-256: What to Check Before It Ships

#git #devops #tutorial #programming

Every commit, tree and file in a Git repository is named by a hash, and for twenty years that hash has been SHA-1. Git 3.0 changes the default for newly created repositories to SHA-256, along with making main the default branch and reftable the default reference store. Repositories that already exist stay exactly as they are.

The catch is everything around Git. A SHA-1 repo and a SHA-256 repo cannot exchange objects, there is no in-place conversion, and as of October 2, 2026 GitHub still had not announced support for SHA-256 repositories. I put together a longer walkthrough, with every command and error reproduced, on DevToolLab. Here is the short version.

Banner comparing a 40-character SHA-1 object ID with a 64-character SHA-256 ID for the same file

Find Out Which Format You Have

One command answers it, and every output below came from Git 2.51.0:

$ git rev-parse --show-object-format
sha1
Enter fullscreen mode Exit fullscreen mode

A SHA-256 repository also records extensions.objectFormat = sha256 in its config, while a SHA-1 repository has no such key at all. If you only have a commit ID from a log or a pull request, its length gives it away: 40 hex characters is SHA-1, 64 is SHA-256. The Hash Identifier does that check in the browser, though only Git can tell you which repository an ID belongs to.

Start a SHA-256 Repository Today

You do not have to wait for 3.0:

$ git init -b main --object-format=sha256 payments-api
Initialized empty Git repository in ~/src/payments-api/.git/
$ git rev-parse --show-object-format
sha256
$ git log --format=%H
f4b5ed84db434c415d929befc3d3c6273fb0f9c59e6cac2e9f042fce735ec599
Enter fullscreen mode Exit fullscreen mode

To make SHA-256 your personal default early, run git config --global init.defaultObjectFormat sha256. For a single terminal session, GIT_DEFAULT_HASH=sha256 does the same job. Clones need nothing extra, because a clone always inherits the format of the repository it came from.

What Git Is Actually Hashing

An object ID is not a hash of the file alone. Git prepends a header made of the object type, the size in bytes and a NUL byte, then hashes the result. Changing the object format only swaps the hash function, which shasum confirms:

$ printf 'Hello, Git\n' | git hash-object --stdin          # in a SHA-1 repo
b7aec520dec0a7516c18eb4c68b64ae1eb9b5a5e
$ printf 'Hello, Git\n' | git hash-object --stdin          # in payments-api
886fb8fd8e66c5a7483536a90f8bb355ac1a36e70e36e6d1872d7f583af8f76a
$ printf 'blob 11\0Hello, Git\n' | shasum -a 256
886fb8fd8e66c5a7483536a90f8bb355ac1a36e70e36e6d1872d7f583af8f76a  -
Enter fullscreen mode Exit fullscreen mode

That header is why pasting file contents into a general hash generator never matches what Git reports. The full article also has a short Python function that computes both IDs without shelling out to Git.

The Rest of Git 3.0, and When It Lands

Git's BreakingChanges document says plainly that there is no planned release date for 3.0 yet. Git 2.56, the newest release, came out on September 28, 2026. SHA-256 itself is old news: it arrived in Git 2.29.0 in October 2020, lost its "experimental curiosity" warning in 2.42.0 in August 2023, and the work on SHA-1 and SHA-256 interoperability only started in 2.52.0 in November 2025.

The same release plans reftable by default, main as the default branch, and safe.bareRepository defaulting to explicit so hooks in a bare repository you happen to cd into do not run. Three old features go away: git whatchanged, git pack-redundant and commit grafts. Rust also becomes a required build dependency. The project also says it has no plan to deprecate SHA-1, and the last release before 3.0 will get long-term support.

For teams selling to the US government, NIST's December 2022 announcement, which set December 31, 2030 as the date to stop using SHA-1, matters more than Git's schedule, and GitLab's docs point to it as a reason to switch.

Your Host Decides First

GitHub is the blocker. In its long-running community discussion, users reported a SHA-256 push failing in June 2024 and an import from Codeberg failing in March 2026, with no announcement from GitHub. GitLab has offered SHA-256 projects as an experiment since 16.7, behind a feature flag that is off by default, and only lets you choose the format when the project is created. Forgejo, which powers Codeberg, has supported it since 7.0, with some features still flagged as unreliable.

GitLab docs section for creating a SHA-256 project, marked as an experiment that is not ready for production use

Converting Means Rewriting History

There is no in-place switch. The workable route is git fast-export --all from the old repository piped into git fast-import in a new SHA-256 one. Files and tags survive, but every commit ID changes, so signatures stop verifying, links to old commits in tickets break, and everyone with a clone has to move at once. Submodules cannot mix formats either; since Git 2.53, git submodule add refuses a repository with a different hash.

The Errors You Will Actually See

Pushing across formats, in either direction, fails like this:

$ git push ../remote.git main
fatal: the receiving end does not support this repository's hash algorithm
fatal: the remote end hung up unexpectedly
Enter fullscreen mode Exit fullscreen mode

Fetching the other way gives fatal: mismatched algorithms: client sha256; server sha1. Running git init --object-format=sha256 inside an existing repository stops with fatal: attempt to reinitialize repository with different hash. Hand-editing extensions.objectFormat produces fatal: repo version is 0, but v1-only extension found. None of them have a flag that makes the mismatch go away.

When to Leave It Alone

If a repository has to live on GitHub this year, keep it on SHA-1, and do not convert an active repository just because a new major version is coming. Scott Chacon of GitButler made the case on October 1, 2026 that SHA-1 was never really the trust boundary, and that commit signing and supply-chain controls protect you more than a longer hash.

Conclusion

Git 3.0 changes what git init creates, not what you already have. Before moving anything to SHA-256, check your current repositories' format, confirm your host accepts SHA-256 pushes, and look through scripts and CI for code that expects 40-character commit IDs. If every check passes, new repositories can start on SHA-256. If any of them fail, wait for 3.0 and for your host.

References

Top comments (0)