Independent benchmark puts Git 2.56 history-drop at 6x over rebase, not 40-77x

Git 2.56, released on September 28, ships with a new experimental command, git history drop, which removes a commit from history by replaying everything that descends from it. A benchmark published by Alex Georgiev on November 13 put the command 40 to 77 times faster than an equivalent git rebase --onto. A day later, a writer on dev.to rebuilt Git 2.56 from source, repeated the same test and measured a 6x speed-up — and the gap between those two numbers is the most useful part of the story.

What was measured

The dev.to writer copied Georgiev's method exactly so the results could sit side by side. Each test builds a fresh repository: one root commit, one target commit to delete, then a series of descendant commits, each touching a shared file plus a file of its own so the replay involves real diff work. The repository is cloned bare twice so both approaches start from byte-identical history.

The old path adds a linked worktree to the bare repository and runs git rebase --onto to skip the target commit. The new path runs git history drop directly against the bare repository, with no worktree at all. Every size was run three times, and after each run the tree hash of the main branch was compared between the two methods. All nine comparisons matched, so the rewrite produced identical results either way.

The numbers side by side

Commits	Rebase (Georgiev)	Drop (Georgiev)	Speed-up	Rebase (dev.to)	Drop (dev.to)	Speed-up
20	1.418s	0.035s	40.7x	0.193s	0.034s	5.6x
100	7.121s	0.092s	77.5x	0.810s	0.139s	5.8x
400	26.525s	0.362s	73.2x	2.258s	0.325s	6.9x

Look at the drop columns first: 0.362s versus 0.325s for 400 commits, on two different machines. The rebase baseline, however, differs by roughly a factor of ten — 26.5 seconds versus 2.3. The headline ratio measures how slow rebase happens to be on a given machine, not a fixed property of the command. The dev.to writer says they cannot see Georgiev's setup and declines to guess whether disk, filesystem or background load explains the slower baseline.

Why it is faster

According to Georgiev's own breakdown, the worktree setup he initially suspected accounted for just 26 milliseconds of a roughly 25-second run. Most of the time goes to rebase cherry-picking commits one at a time and updating the index and working tree after each one, even though nobody inspects those intermediate states. git history drop never touches a working tree; it works on the underlying objects directly. That mechanism held on both machines. It buys a 6x gain where rebase was already fast, and roughly 70x where it was not.

Behaviour beyond speed

Georgiev also verified two behavioural differences, which the dev.to writer carried over but did not re-test. A single history drop updates every branch descending from the dropped commit, whereas a plain rebase rewrites only the current branch. And the command does not run hooks: a post-rewrite hook that fired immediately under rebase never fired during a drop. The man page states hooks are not run "at the current point in time", which reads more like a warning that this may change than a guarantee.

Failures are clean as well. Dropping the root commit or a merge commit fails immediately with a clear error, and a drop that would conflict during replay fails all-or-nothing — no half-finished state, no conflict markers, nothing to clean up. An interactive rebase hitting the same conflict stops mid-sequence with a dirty working tree. The man page calls this a design limitation, on the grounds that history rewrites are not meant to be stateful operations.

Caveats before switching

The man page marks the whole command experimental: "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE." It has four subcommands — drop, fixup, reword and split — and only drop was tested here. Git 2.56 has not reached distribution repositories, so trying it means building from source; the dev.to writer's build needed NO_CURL=1 and NO_RUST=1 to skip missing libcurl headers and the Rust toolchain, which is fine for local tests but produces a binary that cannot speak HTTP. Rust remains optional in Git's build until Git 3.0, and the history command itself is plain C.

Why it matters

For the job the command targets — dropping a commit from a bare repository, the kind of cleanup done on shared repos or long-lived integration branches — the absolute numbers are what count: about a third of a second to replay 400 descendants, identical tree hashes, no throwaway clone or worktree dance, and every descendant branch updated in one pass. The benchmarking lesson matters too: a speed-up ratio is only as good as its baseline, and the reliable way to size this up is to time rebase on your own repository. Anyone wiring the new command into scripts should first check hook dependencies, because post-rewrite hooks stop firing silently.