Looking forward to Git 2.56 – and 3.0
Git is at the core of software development processes worldwide, so changes to it—especially incompatible ones—are of great interest to developers. Git 2.56 is currently available in release-candidate form and is expected around the end of September; it is not the most earth-shaking release, but the release after it may be the long-awaited Git 3.0.
Git 2.56 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 feature with some potential is the addition of the `drop` subcommand to the still-experimental `git history` toolbox: `git history drop commit-id` removes the identified commit from the current branch's history, replaying all commits that were added after it, offering an easier way to remove an offending commit. Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many or most repositories.
Among other changes, `git status` will now suggest a `git pull` to update a branch that is behind the branch it tracks; it still says a branch is up to date even if it lags behind an unfetched remote tracking branch. The low-level `git refs` command gained new `create`, `delete`, `update`, and `rename` subcommands. There are also minor usability tweaks: a new `--delete-merged` option to `git branch` removes local branches that have been merged into their remote tracking branches; `git branch -d` will fail with a useful message if the branch is being used for bisection; attempts to lock the configuration file will be retried on failures to avoid annoyance when multiple commands try to modify it at once; and `git add` has a new `--resolved` option that only adds files with merge conflicts that have been resolved. Beyond that are the usual bug fixes, refactorings, and performance improvements. All told, 2.56 looks like a solid release, but it also shows signs of a project holding back much of its more significant work for the future.
After 2.56, in early September, Git maintainer Junio Hamano asked the community what the next release should be—specifically whether it would be best to put out the 3.0 release that the community has been waiting for. That makes the follow-up release the one to watch for potentially incompatible changes.