The Git source-code management system is at the core of development processes worldwide, so changes, especially incompatible ones, draw close attention from developers. According to the LWN article, the Git 2.56 release is expected around the end of September and is already available as a release‑candidate. It contains something over 700 non‑merge commits and brings a number of nice improvements, though it will not fundamentally change the Git experience for most users. One notable addition is the experimental git history drop subcommand, which can remove an identified commit from the current branch’s history and replay later commits. The article notes that this command still refuses to work when the history contains merge commits, limiting its usefulness in many repositories. Usability tweaks include git status now suggesting a git pull when a branch lags behind its tracked branch, the git refs command gaining new subcommands create, delete, update and rename, and a --delete-merged option for git branch that removes local branches merged into their remote tracking branches. Attempts to delete a branch with git branch -d will fail with a useful message if the branch is being used for bisection, and configuration‑file lock attempts will be retried on failures to avoid annoyance when multiple commands modify the file simultaneously. git add gains a --resolved option that adds only files whose merge conflicts have been resolved. Beyond these changes, the release includes the usual collection of bug fixes, refactorings and performance improvements. The article describes 2.56 as a solid release that also shows signs that the project is holding back more significant work for the future. After 2.56, Git maintainer Junio Hamano asked the community whether the next release should be the long‑awaited 3.0 or another 2.x release. The article explains that moving to 3.0 would involve compatibility breaks, the most significant of which would be switching the default hash function from SHA‑1 to SHA‑256. SHA‑1 has long been considered weak, and while Git already includes defenses against known attacks, moving to a more secure hash makes sense. Non‑experimental SHA‑256 support has existed since Git 2.42 (2023), but the transition has been delayed by the need for support at major forge sites. GitLab and Forgejo already provide it, whereas GitHub’s support is still pending; a GitHub employee and key SHA‑256 developer, Brian m. carlson, indicated that news on that topic was coming and that making the next release 3.0 might be the best choice. carlson also proposed changing Git’s handling of object IDs to accept only lower‑case hexadecimal strings, citing bugs and security vulnerabilities that have arisen from the current case‑insensitive behavior. Another long‑awaited change slated for 3.0 is the adoption of the “reftable” mechanism for storing references. The article notes that the current file‑based .git/refs/ approach becomes inefficient as the number of refs grows—citing the Android repository’s over 800,000 refs as an example. Reftables, introduced as an experimental feature in Git 2.45, provide a binary file optimized for space and speed. While switching to reftable should be transparent to Git users, it could affect external tools that read repositories directly; however, libgit2 has received reftable support from Patrick Steinhardt, and SHA‑256 is already enabled by default in that library. Finally, the article mentions the Rust question: Git has added trial support for Rust code but has hesitated to make a Rust compiler mandatory for building Git. That stance is expected to change in the 3.0 release, meaning that platforms lacking a working Rust compiler would be unable to upgrade to future versions.
