Git 2.56 adds history drop and delete-merged

Git 2.56 is in release candidate form and is expected at the end of September 2026. LWN.net reported that the release carries more than 700 non-merge commits. Most of them are plumbing, but a handful of new commands change what developers can do without reaching for an interactive rebase.

LWN calls 2.56 "a solid release" and says the project is "holding back much of its more significant work for the future." That future is Git 3.0.

The new commands

Command or option	What it does
git history drop	Removes named commits from a branch by replaying the ones after them
git repo info	Prints repository paths, both absolute and relative
git add --resolved	Stages only the merge paths whose conflicts you fixed
git branch --delete-merged	Deletes local branches already merged into their remote tracking branch
git bisect --reset-when-found	Restores the original state once bisect finds the commit
git replay --linearize	Drops merge commits while replaying history
git refs	Creates, deletes, updates and renames references directly

What history drop does, and where it stops

git history drop removes a commit you name from a branch. It works by replaying every commit that came after it. That is the job people currently do with an interactive rebase, typed carefully, one line at a time.

There is a limit worth knowing before you plan around it. Git's release notes say the command still refuses to work if the history contains merge commits. Many real branches contain merges, so the command suits a linear feature branch rather than a long-lived shared one.

git replay --linearize approaches the same ground from the other side. It drops merge commits as it replays, which flattens a tangled history into a straight line.

Smaller changes you will notice

git add --resolved is aimed at a common mid-merge mess. During a conflicted merge you often fix two files and leave other edits in the working tree. The new option stages only the paths whose conflicts you resolved, and leaves your other local changes alone.

git branch --delete-merged clears out local branches that were already merged into the branch they track. Git also prints a clearer message when one of those branches is in use for a bisection.

The Git project's release notes list several quieter fixes. Git now spots typos in commands such as git push origin/main. A new fetch.followRemoteHEAD setting controls how a fetch treats the remote's default branch. Asking any command for help now exits with code 0 instead of 129, which stops scripts from reading a help request as a failure. Configuration commands retry when they collide, which reduces lock errors when two commands write config at once.

Underneath, git cat-file --batch formats output faster, and git log --follow handles non-linear history better than before.

What this means for developers

Try git history drop on a copy of a branch before you trust it on a real one. The merge-commit restriction is the part that decides whether it fits your workflow at all. Run git log --merges on the range you want to edit: if that prints anything, the command will refuse.

git branch --delete-merged is the one to wire into habit. Most developers accumulate dozens of stale local branches and clean them up with a shell pipeline copied from a blog post years ago. A built-in option is safer, because it checks the remote tracking branch rather than matching names.

The exit-code change deserves a scan of your own tooling. Any script that treated 129 as the signal for a help request will now see 0. That is the correct behavior, but it is a behavior change, and it will fail quietly rather than loudly.

Nothing here breaks an existing repository. The changes that will are in the next release: Git 3.0 switches new repositories to SHA-256 and reftable, and makes Rust a required build dependency. Git's own breaking-changes document still gives 3.0 no release date. Treat 2.56 as the last quiet stop before that one.