Git’s next major release is being framed as a coordinated break with several long-standing design choices rather than a routine version bump. In its September 18, 2026 report, LWN says the project is considering Git 3.0 after the expected Git 2.56 release, with compatibility-sensitive changes moving into the major release. The report’s update says the agreed sequence is Git 2.98 in December 2026, Git 2.99 as a long-term-support release in April 2027, and Git 3.0 at the same time. That sequence is reported by LWN; the supplied Git documentation does not independently confirm it.
The article examines major changes to Git’s repository objects, reference storage, and build requirements, making the official project mark a direct identifier. Credit: git-scm.com.
The clearest change is the proposed move from SHA-1 to SHA-256 for Git repositories. Git uses hashes to identify files, directory trees, and commits, and to verify the chain of history. LWN explains that SHA-1 is considered weak and that a successful attack could, in principle, make repository history difficult to trust. Git already includes defenses against known SHA-1 attacks, and LWN reports that non-experimental SHA-256 support has existed since Git 2.42 in 2023. Those statements describe the security rationale and implementation history; they do not show that existing SHA-1 repositories are currently being compromised.
The practical migration question is therefore not simply whether SHA-256 is stronger. It is whether the repositories, hosting services, and tools that surround a project can work together during the transition. LWN reports that GitLab and Forgejo already support SHA-256, while GitHub support was not clearly established in the supplied material. It also reports that brian m. carlson, a GitHub employee and contributor to the transition, said news about the topic was coming and suggested that making the next release Git 3.0 could be appropriate. That is an attributed participant’s view, not a GitHub product announcement or proof of compatibility.
Reftable is the other major storage change under discussion. Git currently stores references such as branches and tags as files under `.git/refs/`, with a `packed-refs` mechanism for some consolidation. LWN cites Git’s reftable documentation when reporting that the Android repository has more than 800,000 refs and that reference-heavy repositories can suffer expensive lookups. Reftable stores references in a binary format intended to use less space and support faster access. Git 2.45 made it possible to create a reftable-backed repository, but the supplied documentation does not establish that reftable is already the default.
The likely benefit is operational rather than visible to most users: large repositories may handle references more efficiently. The likely risk is at the edges, where another program reads or writes a repository without using Git itself. LWN identifies libgit2 as a possible compatibility concern, then reports that Patrick Steinhardt said libgit2 had gained reftable support and enabled SHA-256 support by default in August. That is an attributed development update; it supports the claim that libgit2 was being prepared, but it does not establish that every application embedding libgit2 has shipped the necessary support.
A third proposed change is making Rust mandatory for building Git. LWN reports that Git has trial Rust support but has hesitated to require a working Rust compiler. If that proposal ships, platforms without suitable Rust tooling would no longer be able to build the new Git version. The supplied sources do not specify which platforms would be affected, what compiler versions would be required, or whether downstream distributions would provide alternatives. The evidence therefore supports the existence and consequence of the proposal, not a complete portability assessment.
The discussion cues raise a useful distinction between changing a repository’s object format and rewriting its ordinary commit history. The supplied packet does not contain enough primary documentation to answer whether every SHA-1 repository must be force-pushed, how hosting providers will expose migrated repositories, or how mixed-format submodules will behave. Those questions should remain open rather than being answered from anecdotal comments. What the evidence does establish is that SHA-256 support is already present, that major-version planning is tied to compatibility work, and that forge and tooling readiness are central constraints.
For readers maintaining important repositories, the immediate implication is to inventory dependencies rather than assume that installing Git 3.0 will be transparent. That includes hosted repository providers, CI systems, backup and archival tooling, code-review software, IDE integrations, and libraries such as libgit2. Teams should also distinguish a local experiment with SHA-256 or reftable from a coordinated migration that changes how collaborators and services exchange repository data. The supplied sources do not provide a universal migration procedure, so any deployment plan should wait for the relevant provider and tool documentation.
The most important caveat is timing. LWN’s update presents a specific release sequence, but the packet does not include an independent release announcement or primary Git project document confirming it. Likewise, the source’s exact publication date is clear from the visible LWN byline—September 18, 2026—while the source packet’s generated date is later and should not be treated as the article’s publication date. The safest reading is that Git 3.0 is a planned direction with substantial preparatory work, not a completed transition whose compatibility and schedule are already settled.