Git 2.56: One-Line Commit Drops and New Ref Commands

Git 2.56.0 shipped on September 28, bringing a one-line way to drop commits, new subcommands for editing refs directly, and cleanup flags for git-branch that finally catch branches merged through an integration branch rather than just locally. The release also locks in a concrete timeline for Git 3.0, including SHA-256 becoming the default object hash format. None of this requires anything from you today, but a few of these commands are worth adding to your muscle memory.

Key Takeaways

• git history drop <commit> removes a commit and rebases its descendants in one line, replacing the git rebase -i dance for that specific case
• git-branch gets --forked (list branches tracking a given integration branch) and --delete-merged (delete every branch whose tip has actually landed on that branch's remote)
• git-refs, introduced in Git 2.46, now supports create, delete, update, and rename for working with references directly instead of through git branch or git tag
• git-replay gained --linearize, fixing its previous refusal to rebase history that contains merge commits
• Git 3.0 now has a real schedule: 2.56 (this release) → 2.98 in December 2026 → 2.99 and 3.0 together in spring 2027, with SHA-256 as the default hash, reftable as the default ref storage, and Rust no longer an optional dependency

What does "git history drop" actually do?

Deleting a specific commit from history used to mean git rebase -i, finding the commit in an editor, and manually marking it to drop. Git 2.56 adds a drop subcommand to git-history(1) that does the same thing in one line:

git history drop <commit>

The target commit is removed and its descendants get rebased onto its parent automatically. Like the rest of git-history(1), this also updates every branch that descends from the original commit to point at the rewritten history, so you're not left syncing multiple branches by hand afterward.

What are the new git-branch cleanup flags?

The classic one-liner for cleaning up merged branches — git branch --merged main | grep -v main | xargs git branch --delete — has a gap: it only catches branches merged directly into the branch you ran it against, not branches that forked off main and got merged into origin/main instead. Git 2.56 adds two flags to close that gap. --forked lists branches whose configured upstream matches a given ref, so git branch --forked origin shows every branch tracking origin's branches. --delete-merged goes a step further and deletes every branch whose tip is reachable from its configured upstream — in effect, every feature branch that's actually landed:

git branch --delete-merged origin

This only works if your branches are tracking an integration branch in the first place. If you usually branch off your local main instead, Git's docs point to the inherit setting on the branch.autoSetupMerge config as the fix.

What can you do with git-refs now?

git-refs(1) has been the designated home for reference operations since Git 2.46, previously handling things like migrating refs between storage backends and consistency checks. Git 2.56 adds direct mutation: create, delete, update, and rename, so you can manage references without going through git branch or git tag:

git refs create refs/heads/branch-c main
git refs update refs/heads/branch-u main~1
git refs rename refs/heads/branch-r refs/heads/foo
git refs delete refs/heads/branch-d

Both update and delete accept an optional expected old value, so you can validate the ref's current state before Git applies the change — useful if you're scripting ref changes and want to avoid clobbering something that moved underneath you.

What changed with git-replay?

git-replay(1) is Git's experimental server-side rebase: it can replay a range of commits onto a new base without needing a working tree. Until this release, it flatly refused to touch a range containing merge commits, which made it useless for anything but the simplest linear history. Git 2.56 adds a --linearize flag, mirroring the --no-rebase-merges default in git-rebase(1), so a feature branch with a merged-in bugfix commit can now be replayed cleanly onto a new base instead of erroring out.

What's the actual timeline for Git 3.0?

This release cycle overlapped with Git Merge 2026 in Lisbon, where the Git Contributor Summit settled on a concrete schedule for Git 3.0 — something the project's own breaking-changes documentation previously left undated. The plan: 2.56 is this release, 2.98 ships in December 2026, and 2.99 and 3.0 ship together in spring 2027, differing only in whether the breaking-changes feature flag is turned on. The headline changes in 3.0 are SHA-256 replacing SHA-1 as the default object hash, reftable replacing the current format as the default reference storage, and Rust becoming a required dependency rather than optional. 2.99 will be maintained as an LTS release for platforms that can't get a Rust toolchain. Forge support is part of why this took until now to schedule — GitLab has supported SHA-256 repositories for about a year, while GitHub only announced a private beta at Git Merge, with general availability expected a few months out.

Anything else worth knowing?

Four Google Summer of Code 2026 projects landed in this release, mostly under the hood: git-cat-file(1) can now fetch an object's metadata over the network without downloading the object itself (handy for checking a large blob's size in a blobless clone without pulling it), git-repack(1) gained a --drop-filtered flag to reclaim disk space in partial clones by dropping large blobs back out after they've been fetched, and git-repo(1) info now reports absolute and relative paths for the git directory. Work also continued on making Git's object database pluggable — packfile generation, consistency checks, and housekeeping are being moved out of the core commands and into swappable backends, invisible to users for now but laying groundwork for alternative storage backends down the line.

Wrapping Up

If you only take one thing from this release, make it git branch --delete-merged — it'll clear out more stale branches than whatever grep-and-xargs pipeline you're currently running. The Git 3.0 timeline is also worth bookmarking if your tooling or CI touches object hashes directly; SHA-256 becoming default is still over a year out, but it's no longer vague.

Sources

GitLab — What's new in Git 2.56.0?

Git mailing list — official Git 2.56.0 release announcement