Git 2.56 is out soon, and the people behind it are already looking past it to Git 3.0. The next version of the source-code manager will bring a major change: SHA-256 hashes as the default instead of SHA-1, which has been carried since the beginning. The switch could break compatibility, and the biggest question is whether GitHub will be ready for it.
Git 2.56 arrives soon
The 700-or-more non-merge commits in the 2.56 release candidate cover a new drop subcommand for Git’s experimental history toolbox, bug fixes, and small usability improvements. The drop command lets a user remove a commit from a branch’s history and replay all commits that came after it.
The new –delete-merged option for git branch removes local branches merged into their remote tracking branches. Git add now has an –resolved flag that only adds files with resolved merge conflicts.
The SHA-256 switch
The SHA-1 hash has been known to be weak for some time. It identifies every file, directory tree, and commit in a repository, and its weakness means it could, in theory, be broken to modify a repository’s history without detection.
Git has included defenses against the known attacks on SHA-1 for years. Few people appear to be seriously worried about compromised repositories now. Still, moving to SHA-256 makes sense.
“It still is not clear when GitHub might add that support, but it is notable that brian m. carlson, a GitHub employee and a key developer behind the SHA-256 transition, responded to Hamano’s question by saying that news on that topic was coming, and that that having the next release be 3.0 might be the best choice.”
GitHub’s missing support
Non-experimental SHA-256 support has existed in Git since the 2.42 release in 2023. GitLab has had support since 2024, and Forgejo has it too. GitHub remains the missing piece.
Releasing a version of Git that creates GitHub-incompatible repositories is a worrisome prospect. brian m. carlson, a GitHub employee, has said that news on the topic was coming and that 3.0 might be the best choice.
Other changes on the way
Carlson also wants to change Git’s behavior to only accept object IDs in lower case. Git has always managed hexadecimal numbers as lower-case strings but has also accepted upper-case IDs. Two IDs that look different, like f00f00 and F00F00, are actually the same.
Bugs and security vulnerabilities have arisen from this ambiguity. Carlson wants to change Git to only accept IDs in lower case. That change should not cause problems for too many users, but it is almost certainly somebody somewhere who relies on the current behavior.
What comes next
In early September, Git maintainer Junio Hamano asked the community what the next release should be. Should it be the long-awaited Git 3.0, finishing the year on a high note? Or is there a need for one or more 2.x releases before 3.0?
The compatibility breaks in 3.0 may make some users pause before upgrading. The SHA-256 switch is the most significant of those breaks. Other changes waiting for 3.0 include the switch to the “reftable” mechanism, which changes how Git stores references to branches, tags, and remotes.
The release schedule
| Release | Status |
|---|---|
| Git 2.56 | Release candidate |
| Git 3.0 | Pending |
2.56 shows signs of a project holding back significant work. The full SHA-256 shift and the other pending changes will land somewhere down the line. Whether GitHub is ready for it remains the open question.
For now, users can expect 2.56 to arrive around the end of September, with the full SHA-256 shift hanging on the GitHub piece.
Source material: “Looking forward to Git 2.56 – and 3.0,” lwn.net.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.