Git 2.56 Hits Release Candidate, and 3.0 Hinges on GitHub

Git 2.56 is in release-candidate form now, with the final release expected around the end of September, and carries something over 700 non-merge commits. “It is not the most earth-shaking of releases.” Nothing in it will fundamentally change how most people use Git. The release that follows, which might be the long-awaited 3.0, could.

The one addition with real promise is drop, a new subcommand of the still-experimental git history toolbox: it removes the identified commit from the current branch and replays every commit that was added after it. That is the tool I want whenever a stray commit has to disappear, and it refuses to work on any history containing merge commits, which rules out most of my repositories. The rest is polish. git status now suggests git pull for a branch that is behind the branch it tracks, git refs gained create, delete, update and rename, git branch --delete-merged clears branches already merged into their remote tracking branches, and git add --resolved stages conflicted files whose conflicts are resolved.

What comes next is the real question. Junio Hamano asked the community in early September whether the next release should be 3.0 or whether one or more 2.x releases are still needed first, because 3.0 will carry compatibility breaks that make people pause before upgrading. The largest is the default switch to SHA-256 in place of SHA-1, which Git has used since the beginning. Hashes identify every object (files, directory trees, commits) and verify the chain of commits leading to any given point, so a hash that can be broken could let history be modified in ways that are hard or impossible to detect.

The delay has never been about Git’s own code: non-experimental SHA-256 support has existed since the 2.42 release in 2023, GitLab has had support since 2024, and Forgejo does too. GitHub is the one still missing, and a Git that creates repositories GitHub cannot host is an unpleasant prospect. Brian m. carlson, a GitHub employee behind much of the SHA-256 transition, answered Hamano that news on the topic is coming and that making the next release 3.0 might be the best choice. He also wants Git to accept object IDs in lower case only, since f00f00 and F00F00 are currently the same ID, and that ambiguity has produced bugs and security vulnerabilities.

Two more 3.0 changes are staged: reftables as the default storage for refs, and mandatory Rust for building Git, which would strand any platform without a working Rust compiler. libgit2, the usual worry for other software that reads repositories, is ready, with reftable support in and SHA-256 its default since August. My plan is to take 2.56 without reading the notes twice and treat 3.0 as the release that matters. Editor’s note: I want to run drop on a scratch clone with a merge in it, just to see the refusal message for myself. Android’s repository carries over 800,000 refs, mine a few hundred; run git for-each-ref | wc -l in your largest repository before reftables become the default.