Git 3.0's Biggest Change Is Stuck Behind One Holdout: GitHub

Git 2.56 is due near the end of September 2026 carrying more than 700 non-merge commits, according to Git maintainer Junio Hamano's own What's Cooking in Git.git mailing list status reports and LWN editor Jonathan Corbet's Sept. 18 analysis of the release. None of that list changes how most people use Git day to day, at their keyboards. The release that will is Git 3.0, and its most disruptive default, switching from SHA-1 to SHA-256 hashing, is still waiting on a single holdout forge: GitHub.

What actually ships in 2.56

Corbet's LWN piece lists the concrete additions: an experimental git history drop subcommand that removes a chosen commit and replays everything after it, though it does not yet work across merge commits; a git status warning that suggests git pull when a branch has fallen behind its remote tracking branch; new git refs create/delete/update/rename subcommands; a git branch --delete-merged flag; a safeguard that stops git branch -d from deleting a branch that is in active use for a bisection; retry logic when multiple commands try to lock the same config file at once; and git add --resolved, which stages only files whose merge conflicts have actually been resolved and scans for leftover conflict markers. Phoronix's Sept. 11 report on the 2.56-rc0 tag adds that the release also brings Swift-language patterns to git diff and hardens the ORT merge backend against corrupt trees.

The three changes that don't ship quietly

Git 3.0, expected around the end of 2026, carries changes Git's own developers have flagged as compatibility-breaking: SHA-256 becomes the default hash function instead of SHA-1, reftable becomes the default reference storage format in place of the old file-based layout, uppercase hexadecimal object IDs stop being accepted, and building Git from source starts requiring a working Rust compiler, according to Corbet's reporting on the mailing list discussion.

Git 3.0 change	What it breaks
SHA-256 default hash	Repos and forges without SHA-256 support can't interoperate by default
Reftable default ref storage	Tools that read .git/refs files directly
Lowercase-only object IDs	Scripts or tools that pass uppercase hex IDs
Rust compiler required to build	Any platform without a working Rust toolchain

Of the four, SHA-256 is the one that depends on infrastructure Git's own maintainers don't control. GitLab added SHA-256 support in 2024 and the smaller forge Forgejo supports it too, but GitHub, the forge most Git users actually push to, has not, according to Corbet's piece. Brian M. Carlson, a GitHub employee who has architected much of Git's SHA-256 transition, is quoted in the same report saying "news on that topic was coming," which reads as the closest thing to an acknowledgment from inside GitHub that support is planned rather than shipped.

Carlson's own assessment of who else still needs to catch up was blunt: "I think anyone else who is not already extremely far along on SHA-256 (and reftable, for software working with local repositories) is likely not worth considering." Hamano, pushing back in the same mailing list thread against the idea that Git 3.0 should wait for full consensus before shipping, wrote that "this is not a popularity contest, nor is it even a democracy."

The counter-case

Most Git users will not notice a SHA-256 default on day one, because existing SHA-1 repositories keep working under Git 3.0 without conversion; the default only governs new repositories. The Rust build requirement and the reftable switch touch more people sooner: anyone building Git from source on a platform without Rust packaging, or any tool that parses .git/refs files directly instead of calling Git's own plumbing, breaks regardless of what GitHub does with SHA-256. Framing GitHub as the sole blocker overstates SHA-256's centrality to the release even if it accurately describes why Git's developers keep citing it as the one dependency outside their own control. Corbet's reporting treats the Rust requirement as a separate fight entirely, one that affects any platform lacking a working Rust compiler and has nothing to do with what GitHub ships, which means Git 3.0 carries at least two distinct sources of breakage that a single GitHub announcement would not resolve.

Carlson's line about "news on that topic" is also the detail that could undercut the whole framing before Git 3.0 ships at all: if GitHub adds SHA-256 support before the end of 2026, as Carlson's comment implies is plausible, the loudest objection to shipping the new default disappears, and Git 3.0's actual disruption for most developers narrows to the Rust toolchain requirement.

The repository that would show whether Git-history tooling itself is ready for a hash-format change is the kind of project The Terminal covered Sept. 21, when Z.ai open-sourced its ZCode coding agent after apologizing for silently uploading users' Git history; a hash-function change touches every tool in that category, from IDE integrations to the kind of GitHub-trending open-source projects that read repository state directly instead of shelling out to git.

What would change this read is a GitHub announcement of SHA-256 support landing before Git 3.0's own release, which would turn the current story, a major default stalled by one company, into a footnote about sequencing rather than dependency.

Sources

1. Looking forward to Git 2.56 — and 3.0, LWN.net
2. Git 2.56-rc0 Released With Updated Contribution Guidelines, Improvements For Swift, Phoronix