Git 3.0 will default to SHA-256 and require Rust

Git 2.56-rc0 was published on September 11, 2026, and the release after it is the one that breaks things. Git's own breaking-changes document lists what version 3.0 changes for new repositories. They will use SHA-256 hashes instead of SHA-1, store references in the reftable format, and name the first branch main. Building Git will also require Rust. Phoronix reported the release candidate and put Git 3.0 at around the end of 2026.

Each of those defaults only applies to repositories created after the change. Existing repositories keep working as they are.

The four defaults that change

Default	Today	In Git 3.0
Hash algorithm	SHA-1	SHA-256
Reference storage	files	reftable
First branch name	master	main
safe.bareRepository	all	explicit

The hash change is the one with a security argument behind it. Git's document cites three attacks on SHA-1 by name: SHAppening in 2015, SHAttered in 2017, and Shambles in 2020. A hash collision in a version control system means two different objects can claim the same identity.

Reftable replaces the old layout where each reference was a file on disk. Git's document gives two reasons: it behaves correctly on Windows and macOS file systems that ignore letter case, and it performs better on repositories with many references.

safe.bareRepository moving from all to explicit is a smaller change with a real attack behind it. The current default lets Git discover a bare repository anywhere in a directory tree, including one an attacker planted inside a checkout.

Rust becomes required

The Rust requirement arrives in steps rather than at once. Git's document describes the sequence: Rust support was auto-detected in Git 2.52, enabled by default in 2.55, and becomes mandatory in 3.0.

That places Git alongside other base-layer software taking the same step; Ubuntu is replacing GNU coreutils with Rust implementations in its next release. For anyone who builds Git from source on an unusual platform, a Rust toolchain is now a prerequisite to plan for, not an option.

Git 3.0 also removes features that have been deprecated for years, including git pack-redundant, git whatchanged, graft file support, and older remote storage mechanisms.

What 2.56 itself ships

The release notes for 2.56 are mostly performance and plumbing. Enumerating loose objects during git status drops from quadratic to O(n log n) complexity. Merge-base computation stops early where it can, which the notes describe as producing significant speedups.

There is one new command surface: git refs gains subcommands to create, delete, update, and rename references. The git status advice text now names the remote and branch in the git pull command it suggests when your branch and its upstream have diverged.

Phoronix notes 2.56 also adds diff patterns for Swift, covering attributes, modifiers, failable initializers, and generics, and hardens the ORT merge backend against corrupt trees. Underneath, the release continues removing global variables in favor of per-repository state, which is the groundwork for pluggable object database backends.

What this means for developers

The compatibility question is not whether your Git works, but whether your forge does. A SHA-256 repository must be understood by everything that touches it, including your hosting provider, your CI runners, and any tool that parses object identifiers. Test that path before you create a repository with the new default.

Check your own code for hard-coded assumptions about hash length. Forty hexadecimal characters is a number that has been baked into scripts, regular expressions, and database columns for twenty years. SHA-256 object names are sixty-four characters, and a varchar(40) will simply truncate them.

Reftable is worth adopting early if you carry repositories with thousands of branches or tags, since that is where the format pays off. The branch-name default matters least of all: most teams set it years ago, and a repository created after the change can still be renamed in one command.