Git SHA-256 Transition in 2026: Readiness Data for Every Layer

Git's move to SHA-256 is real but unfinished. Git's own breaking changes document says Git 3.0 will create new repositories with SHA-256 by default, and it also says "There is no planned release date for this breaking version yet." Core Git has handled SHA-256 repositories since 2020. The lag sits in libraries, hosting platforms and the tools that assume a commit ID is 40 hex characters.

That gap matters more than the hash. A SHA-256 repository works on a laptop today and fails the moment it meets a library that cannot parse a 64 character object ID, a hosting service that refuses the push, or a provenance pipeline that validates commit IDs with a regular expression written in 2015.

Key takeaways

• Git 3.0 changes defaults, not history. New repositories will use SHA-256, the reftable reference format and a main default branch. Git states that it has "no plan to deprecate the 'sha1' object format at this point in time." Existing SHA-1 repositories keep working.
• There is no official release date. Git's breaking changes page gives none. A 2025 Phoronix report described a contributor hope of "by the end of next year", and an October 2026 blog post reports an April 2027 date attributed to press coverage. Treat both as reported, not announced.
• SHA-1 in Git is weakened, not collapsed. Since v2.13.0 Git has used a hardened SHA-1 that is not vulnerable to SHAttered, per Git's transition design document.
• SHA-1 and SHA-256 repositories still do not interoperate. The git init manual still says "there is no interoperability between SHA-256 repositories and SHA-1 repositories."
• Readiness is uneven. Core Git and at least one open source self hosted forge create SHA-256 repositories today. libgit2 still labels SHA-256 experimental. JGit has an open issue and no merged support. Large hosted platforms are the main reported blocker.
• Expect breakage in your own tooling. Anything that validates 40 hex IDs, pins by commit, or writes commit IDs into SBOMs and attestations needs a test with 64 character IDs.
• Signing changes shape, not purpose. The transition design adds a gpgsig-sha256 header so a commit or tag can carry a signature over its SHA-256 form, its SHA-1 form, or both.

What exactly does Git 3.0 change?

Git's living BreakingChanges document lists what the next major version will change, and says decisions may be revisited. As fetched on 23 October 2026:

Source: Git BreakingChanges.

The same document also lists removals that will break old scripts, including grafts, git pack-redundant and git whatchanged, and it plans a long term support release before 3.0 with security fixes for six release cycles.

Two details are easy to miss. The hash change applies to new repositories only; nothing converts an existing one. And the default flips only when libraries and forges can cope, which is why the date question has no clean answer.

The reftable change rides along

Reftable is a separate change, but it lands with SHA-256 and shares its precondition. Git lists its advantages as no case sensitivity collisions on Windows and macOS, atomic multi reference writes, tombstone deletes and a smaller binary format. Treat the two as a pair. A library that can read SHA-256 objects but not reftable references will still fail on a default Git 3.0 repository.

Is there a release date for Git 3.0?

No. Git's BreakingChanges page says plainly that there is no planned release date for the breaking version, and it notes that breaking releases have historically been separated by gaps "measured in multiple years". Version 1.6.0 shipped in August 2008 and 2.0 in May 2014, per the same page.

Several secondary sources have published dates anyway. Here is what each says, and how much weight it deserves.

The honest planning assumption: Git 3.0 could arrive within a year or slip, and nothing you need to do depends on the date. What matters is whether your stack breaks when someone creates a SHA-256 repository, and you can test that today.

How weak is SHA-1 in Git specifically?

Git names every object by hashing its content, and objects point to each other by ID. A signed tag signs a few lines of text that include a commit ID, so the signature is only as strong as the guarantee that the ID names one and only one commit.

Git's BreakingChanges page lists the public attacks that motivated the change. We have added the cost figures from the SHAttered site.

Sources: Git BreakingChanges, shattered.io, NIST, GitButler.

Collision detection is the reason Git is not broken today

The SHAttered site says Git added collision detection after the attack. Git's transition document is more precise: since v2.13.0, Git uses a hardened SHA-1 implementation that is not vulnerable to the SHAttered attack.

That mitigates known techniques; it does not fix the algorithm. Git's own document still calls SHA-1 weak and says that if it were broken further, hash values could no longer be trusted to identify intended content. It also lists "retroactively securing existing SHA-1 signatures" as a non goal of the transition. Old signatures stay exactly as strong as SHA-1 is.

The opposing view, stated fairly

Not everyone thinks the migration is worth the cost. Scott Chacon argues on the GitButler blog that trust in Git comes from where you fetch, not from the hash, and proposes keeping SHA-1 for content addressing while adding independent signed SHA-256 or BLAKE3 content hashes to tags and commits. That is one practitioner's position; Git's maintainers chose the SHA-256 path, and NIST's direction is to move off SHA-1 for security uses. Both views agree that tools assuming SHA-1 forever will break.

Can SHA-1 and SHA-256 repositories interoperate today?

Not in a release you can rely on. Git's git init manual states that there is currently no interoperability between SHA-256 repositories and SHA-1 repositories. A SHA-256 clone cannot fetch from or push to a SHA-1 server, and submodules only work between repositories of the same format.

The design for interoperability is written down. In Git's hash function transition document, a SHA-256 repository sets two extensions in its config:

[core]
	repositoryFormatVersion = 1
[extensions]
	objectFormat = sha256
	compatObjectFormat = sha1

With compatObjectFormat, the repository keeps a two way mapping between SHA-256 and SHA-1 names. Pack index version 3 stores both, and a small loose-object-idx file maps loose objects. When fetching from a SHA-1 server, the client would convert the received pack to SHA-256 and keep the mapping. When pushing, it would convert objects back to their SHA-1 form so the server never needs to know. Blobs are byte identical in both forms. The plan defines four command line phases, from a dark launch that hides SHA-256 to a mode that only speaks SHA-256.

The design also has a per command escape hatch for naming objects in either format:

git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}

How far this has shipped is less clear. Git 2.45's release notes say "Work to support a repository that work with both SHA-1 and SHA-256 hash algorithms has started." The 2.42 notes softened the old warning about SHA-256 being an "experimental curiosity" while confirming there was still no interoperability. The transition document itself does not say what is implemented; it is a design. Phoronix reported in October 2025 that interoperability "isn't fully complete". The safest reading for planning is the one in the git init manual: treat the two formats as separate worlds until your Git release notes say otherwise.

On the wire, the protocol is ready to negotiate. Git's protocol v2 documentation defines an object-format capability. A server that does not advertise it is assumed to handle SHA-1 only, and a client that wants another hash must say so. That is the mechanism behind the push failures people report against hosts that do not support SHA-256: the server simply does not advertise object-format=sha256.

Readiness by layer: the ranked table

This is the core of the post. Each row is scored on what the project's own documentation or tracker says as of 23 October 2026. We rank by how close each layer is to handling a default Git 3.0 repository: SHA-256 objects plus reftable references, created, read, written and transferred.

Following our editorial policy, hosting platforms are described by category rather than by name.

Sources for every row are listed in the Sources section at the end. The readiness column is our judgement from those sources, not a vendor claim.

Three patterns stand out.

The C implementation is far ahead of the libraries. Many IDEs, build servers and code review tools link a library instead of calling git. JGit and libgit2 sit under much of that tooling, and neither has supported, default on SHA-256 today.

Hosting is the visible blocker. Both the GitButler author and the Phoronix report point at forges. A secondary blog quotes the error as "the receiving end does not support this repository's hash algorithm", and the GitButler author calls the push failure "probably the main thing currently delaying 3.0 entirely."

Reftable support trails SHA-256 support in places. go-git's compatibility page does not mention reftable at all, and libgit2's changelog does not mention it in the entries we read. A library can be SHA-256 ready and still fail on a default Git 3.0 repository.

What breaks: the 40 hex assumption

A SHA-1 object ID is 40 lowercase hex characters. A SHA-256 object ID is 64. Anywhere software checks, stores, truncates or compares commit IDs can break.

The provenance row is the one most likely to fail quietly. The in-toto attestation digest set specification defines gitCommit, gitTree, gitBlob and gitTag as "the lowercase hex SHA-1 (40 character) or SHA-256 (64 character)" of the object. The standard is ready. The question is whether every verifier and policy engine in your path handles the longer value. Under the interoperability design, one commit has two IDs, and a policy that allows one may not recognise the other.

SBOMs carry the same risk in a different place. Formats such as CycloneDX and SPDX can record where a component's source came from, and many generators fill that with a repository URL and a commit. Consumers that validate the commit with a 40 character pattern will reject SHA-256 references.

Signed commits and tags: does SHA-256 change signing?

Signing works the same way conceptually: a GPG, SSH or X.509 signature over the object's text. What changes is which text is signed and where the signature lives. Git's transition document specifies the following.

Source: Git hash function transition.

Four practical consequences follow.

1. A signature only protects what it names. A signed SHA-1 commit names its tree by SHA-1. If an attacker could produce a colliding tree, the signature would still verify. A SHA-256 signature closes that gap for new objects. It does nothing for history.
2. Converting a repository changes every ID. Rewriting a SHA-1 repository as SHA-256 creates new commits with new IDs, and their old SHA-1 signatures do not carry over automatically. The GitButler author notes that converting existing projects would break existing signatures and SHA-1 links.
3. Dual signing is the planned bridge. The design's later phases make dual signatures the default, then SHA-256 only signing at least a year after, then SHA-256 only repositories. Old git verify-commit versions can verify SHA-1 and dual signed commits.
4. Your signing tool is not the problem; your verifier might be. Verification tooling that extracts the signature by looking for a gpgsig header needs to understand gpgsig-sha256.

For hands on signing setup, see our guides on signing Git commits with an SSH key, verifying a signed Git tag before you build and keyless commit signing. The comparison of commit signing and repository integrity tools covers how each approach ties a signature to an object ID.

How Subversion handles hashing, for contrast

Subversion takes a different approach because its revisions are numbered by the server, not named by content hash. It still computes SHA-1 internally, which is why SHAttered affected it too.

The Apache Subversion security page lists a SHA-1 advisory with the summary "Apache Subversion is unable to store SHA1 collisions," affecting versions 1.1.0 through 1.8.17 and 1.9.0 through 1.9.5. The page lists no CVE and no date for that entry, and it does not name the fixed releases; the affected ranges end at 1.8.17 and 1.9.5. In plain terms, affected versions could not correctly store two different files that share a SHA-1 hash, which is exactly what the SHAttered PDFs are.

Source: Apache Subversion security.

The contrast shows why Git's transition is harder. In Subversion, the hash is plumbing that users rarely see. In Git, the hash is the user interface: it is the commit ID in every link, pin, log line and attestation.

Where Anthropic's Scion fits

Anthropic published an engineering post on 13 October 2026, updated 15 October, describing Scion, the in house version control system that replaced Git for Anthropic's monorepo. Scion is internal to Anthropic and has not been released; Anthropic says it is "by no means a suitable replacement for git for general use."

On hashing, the post says all source control data is content addressed and that changesets point to compressed file contents in blob storage by content addressed pointers. It does not name the hash algorithm. It does not describe commit ID format, and it does not mention commit or changeset signing. We will not guess: Scion's hash choice is not public. The post also says its client deviates from Git's fetch protocols, so Git's SHA-256 transition does not directly apply to it.

What to do now: a step by step readiness test

None of this requires waiting for Git 3.0. Here is a test you can run in an afternoon.

Step 1: check your Git versions

git --version
# SHA-256 repositories need 2.29 or later on every client and server.
# Reftable needs 2.45 or later.

Collect this from developer machines, CI images and any server side Git. The Git for Windows build you ship counts too.

Step 2: create a Git 3.0 style test repository

git init --object-format=sha256 --ref-format=reftable --initial-branch=main sha256-test
cd sha256-test
git rev-parse --show-object-format     # prints sha256
git config --get extensions.objectFormat
echo "readiness test" > README.md
git add README.md
git commit -m "first SHA-256 commit"
git rev-parse HEAD | awk '{ print length($0) }'   # prints 64

You can also make every new repository on one machine default to SHA-256 for a trial week:

git config --global init.defaultObjectFormat sha256
git config --global init.defaultRefFormat reftable
git config --global init.defaultBranch main
# Or for one shell only:
export GIT_DEFAULT_HASH=sha256

The git init manual says both the command line option and GIT_DEFAULT_HASH take precedence over the config value. Undo the global settings when the trial ends, because repositories you create during it cannot be converted back.

Step 3: test your hosting path

git remote add origin <your-forge-test-repo-url>
git push -u origin main

If the server does not advertise SHA-256, the push fails. Record the error for each host and mirror. On a self hosted forge, check whether repository creation offers a hash choice and which Git backend it uses.

Step 4: inventory 40 hex assumptions in your code

# Regexes and validators that hard code 40 hex characters
grep -rEn '\{40\}|\[0-9a-fA-F\]\{40\}|\[a-f0-9\]\{40\}|length *(==|===) *40' \
  --include='*.py' --include='*.js' --include='*.ts' --include='*.go' \
  --include='*.java' --include='*.rb' --include='*.sh' --include='*.yml' .

# Database schemas with 40 character commit columns
grep -rEn '(CHAR|VARCHAR)\(40\)' --include='*.sql' .

# Workflow steps pinned by full commit ID
grep -rEn 'uses: *[^@ ]+@[0-9a-f]{40}' .github/workflows/

Each hit is a candidate, not a bug. Look at what it validates and whether a 64 character ID would pass.

Step 5: test Git dependencies in package managers

Add a dependency that points at a commit in your SHA-256 test repository, using whichever form your ecosystem supports, for example:

# requirements.txt
mypkg @ git+https://<forge>/<org>/sha256-test.git@<64-hex-commit>

# package.json
"mypkg": "git+https://<forge>/<org>/sha256-test.git#<64-hex-commit>"

# go.mod (Go records an abbreviated commit in pseudo-versions)
require example.com/sha256-test v0.0.0-20261023000000-<abbreviated-commit>

Run install, update the lockfile and run the build. Note which tool fails and where.

Step 6: test SBOM and provenance consumers

Generate an SBOM and a provenance statement from the test repository using your usual tools. Then run them through every consumer: SBOM validators, policy engines, artifact registries and anything that compares a gitCommit digest against an allow list. Confirm that the 64 character value survives every hop without truncation.

Step 7: check which Git library each tool embeds

For each IDE, CI runner, code review tool and internal service, find out whether it calls the git binary or links libgit2, JGit, go-git or Gitoxide. An SBOM of your internal tools answers this quickly.

Step 8: decide your default

For most teams the right call today is to keep SHA-1 for repositories that must live on a host without SHA-256 support, and to pilot SHA-256 for new internal repositories on infrastructure you control. Write the decision down, including the trigger for revisiting it, such as your primary host announcing support.

How Safeguard fits

Safeguard is a supply chain security platform, so it helps with the parts of this transition that are about knowing what you run. It generates and ingests SBOMs in CycloneDX and SPDX formats and scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name> or --sbom <file>). Git libraries such as libgit2, JGit, go-git and the Gitoxide crates show up as components, and the platform shows which projects contain a given component and version. That answers step 7 above: which of your services carry an experimental libgit2 build or a JGit version without SHA-256 support.

Safeguard's policies and gates run in the platform, so you can write a rule against a component version once you decide which library releases you accept. The Safeguard CLI's assistant can also run the grep inventory in step 4 and propose edits, asking before each command under its /permissions modes.

Where it does not help: Safeguard does not change what your hosting platform supports, it does not convert repositories, and we have not confirmed with engineering that Safeguard has been tested end to end against SHA-256 repositories. Test your own SBOM and provenance path with a 64 character commit before you depend on it.

Fix it without waiting for upstream

The SHA-256 transition is a slow upstream change, but the vulnerabilities in the Git libraries and tools you depend on are not. While you wait for libraries and hosts to finish SHA-256 support, you still need to keep libgit2, JGit, go-git and Git itself patched.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Common mistakes

• Treating Git 3.0 as a migration deadline. It changes the default for git init. It does not convert or deprecate your existing SHA-1 repositories, and Git says it has no plan to deprecate SHA-1.
• Quoting a release date as fact. Git has published none. Dates in blogs and news coverage are reported intentions.
• Testing only the Git binary. Core Git is the most ready layer. The failures will come from libraries and services that embed JGit, libgit2 or older go-git builds.
• Creating SHA-256 repositories on a host that cannot accept them. The git init choice is permanent in practice. One self hosted forge's own release notes call it "irreversible".
• Forgetting reftable. A default Git 3.0 repository uses reftable references too. Test both formats together.
• Assuming signatures carry over in a conversion. Rewriting creates new IDs; keep the original SHA-1 repository read only to preserve trust in old releases.
• Comparing commit IDs across formats as strings. Under the interoperability design one commit has two names. Normalise before comparing in allow lists and attestations.

How we measured

We built every table in this post from sources fetched on 23 October 2026.

• Git's own position comes from three Git documents: BreakingChanges, the hash function transition design and the git init manual, plus the protocol v2 documentation for the object-format capability. Release behaviour for 2.29, 2.42 and 2.45 comes from the release notes in Git's own repository.
• Library readiness comes from each project's own artefact: libgit2's changelog, go-git's compatibility page, Gitoxide's crate status page and JGit's public issue tracker. We did not run code against each library.
• Hosting readiness comes from one self hosted forge's release blog and one commercial platform's public planning epic. For the largest public host we found no first party statement and relied on two secondary sources, which we label as reported.
• Ranking method. We ranked layers by how much of a default Git 3.0 repository each can handle according to its own docs: create, read, write and transfer SHA-256 objects, handle reftable references, and whether the project labels the support experimental.
• Where sources disagree, we say so below rather than reconcile them.
• What we did not measure: adoption numbers. No source we found publishes how many SHA-256 repositories exist on any host.

Where the sources disagree

FAQ

When is Git 3.0 coming out?

Git has not announced a date. Its BreakingChanges document says there is no planned release date yet. A 2025 Phoronix report described a contributor hope of the end of 2026, and an October 2026 blog reports April 2027. Both are reported, not official.

Will Git 3.0 convert my existing repositories to SHA-256?

No. The SHA-256 default applies to new repositories created with git init. Git says it has no plan to deprecate the SHA-1 object format.

Can I use SHA-256 in Git today?

Yes, with git init --object-format=sha256 on Git 2.29 or later. Git dropped the experimental warning in 2.42. The catch is that SHA-256 repositories cannot exchange objects with SHA-1 repositories, and some hosts and libraries do not support them.

Is SHA-1 in Git broken?

SHA-1 as an algorithm has practical collision attacks, starting with SHAttered in 2017. Git itself has used a hardened SHA-1 since v2.13.0 that detects SHAttered style collisions. The risk is real but mitigated for known techniques.

Can I convert a SHA-1 repository to SHA-256?

Git's interoperability design describes converting objects between formats, but there is no supported in place conversion in released Git that we could confirm. Any conversion rewrites every commit ID and invalidates SHA-1 signatures and links.

Do I need new GPG or SSH keys for SHA-256 commits?

No. Your keys stay the same. SHA-256 commits carry their signature in a new gpgsig-sha256 header, and commits can be signed in SHA-1, SHA-256 or both forms. Your verification tooling needs to understand the new header.

Which Git hosting services support SHA-256 repositories?

At least one open source self hosted forge has supported SHA-256 repository creation since its 1.22 release in May 2024. Support on large commercial hosts is disputed or reported as unavailable in our sources. Test a push to your own host before you commit.

Does my CI system support SHA-256 checkouts?

It depends on whether the checkout uses the Git binary or an embedded library, and on what your host supports. We found no first party statement for any specific CI system in our sources. Run step 3 and step 6 of the walkthrough in a sandbox.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal and ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval and pushes nothing. The same approval flow is how you would have the assistant run the 40 hex grep inventory from step 4 and propose changes to validators, one approved command at a time.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. That is the path for scanning internal tools and CI images on infrastructure you control, so you can see which Git libraries and versions each one carries before you pilot SHA-256.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which projects contain a given libgit2 or JGit version in plain language instead of writing the query yourself.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation. For background on where SHA-1 still appears outside Git, see SHA-1 status and where it still shows up and our note on SSH algorithm brownouts on a large Git host.

Quick check

Sources

• Git BreakingChanges
• Git hash function transition design
• git init manual
• Git protocol v2
• Git 2.29 release notes
• Git 2.42 release notes
• Git 2.45 release notes
• libgit2 changelog
• go-git compatibility
• Gitoxide crate status
• JGit issue tracker, SHA-256 search
• Self hosted forge 1.22 release notes
• Commercial DevOps platform SHA-256 planning epic
• in-toto attestation digest set
• SHAttered
• NIST retires SHA-1
• Apache Subversion security advisories
• Anthropic Engineering: Redesigning source control at Anthropic
• Phoronix: Git 3.0 release talk
• GitButler: Git 3 and SHA-256 (opinion)
• marcpope.com: reported Git 3.0 timeline

Last reviewed: 23 October 2026. SHA-256 support changes release by release; check each project's own documentation for the latest status.