Looking forward to Git 2.56 — and possibly Git 3.0

Git 2.56 in release-candidate form

Git 2.56 is expected around the end of September 2026 and is currently available as a release candidate. It contains something over 700 non-merge commits and, as LWN's Jonathan Corbet writes, brings a number of welcome improvements without fundamentally changing the Git experience.

The most interesting addition is the drop subcommand in the still-experimental git history toolbox: git history drop commit-id removes the given commit from the current branch's history and replays every commit added after it. The command still refuses to work when the history contains merge commits, which makes it unusable for many repositories.

Usability changes

git status will now suggest a git pull to update a branch that is behind the branch it tracks. The low-level git refs command gained new subcommands — create, delete, update and rename — which do exactly what their names suggest.

The new --delete-merged option to git branch removes local branches that have already been merged into their remote tracking branches. git add gained a --resolved option that stages only files whose merge conflicts have been resolved.

After 2.56: the Git 3.0 question

In early September, Git maintainer Junio Hamano asked the community whether the next release should be 3.0 or whether more 2.x releases are still needed. The question matters because 3.0 will bring compatibility breaks, the largest being the switch to SHA-256 hashes by default instead of SHA-1.

Non-experimental SHA-256 support has existed since the 2.42 release in 2023, but the lack of support at major hosting sites held the change back: GitLab has supported it since 2024 and Forgejo does too, while GitHub is the notable exception.

brian m. carlson, a GitHub employee and a key developer behind the transition, said news is coming and that making the next release 3.0 might be the best choice. He also wants Git to reject upper-case object IDs before 3.0.

Another change waiting for 3.0 is the switch to reftable, a binary format for storing references introduced in Git 2.45; the file-based mechanism becomes inefficient as refs grow, and the Android repository holds more than 800,000 of them. Other software that reads repositories has to catch up: carlson named libgit2 as a concern, and Patrick Steinhardt has since added reftable support there. The project also plans to make Rust mandatory for building Git, which would leave platforms without a working Rust compiler unable to upgrade.

carlson argued that none of this should hold up the release, and repositories using SHA-1 without reftables will remain fully supported. Hamano has not announced a decision yet; as he put it, "this is not a popularity contest, nor is it even a democracy". If 3.0 does not arrive in 2026, it will show up shortly afterwards.