Git's new 'history' command borrows jj's best tricks — no new tool required

Git 2.54 and 2.55 quietly shipped an experimental git history command that tackles the pain of reworking commits deep in a stack. It offers three subcommands: fixup folds staged changes into an old commit and auto-rebases everything on top; reword edits an earlier commit message; and split breaks one commit into two through an interactive, hunk-by-hunk prompt. Together they cover common cases that normally require nervous rebase -i sessions.

The standout behavior is how far the rewrites propagate. Unlike rebase --update-refs, which only moves refs inside the range being rebased, git history finds and rewrites every local branch descended from the target commit — though it can be scoped to the current branch, and it refuses to operate across merge commits. Every operation is atomic: rather than risk leaving a half-broken tree, it aborts outright on anything that would produce a conflict. That makes it strictly less capable than jj, which treats conflicts as first-class state and can carry them through a rebase, but Git’s docs signal the restriction could be lifted if first-class conflicts ever land.

The significance is accessibility. The author, a repeated jj tourist who keeps drifting back to Git, argues that git history delivers a big chunk of jj’s appeal — editing history without babysitting branch tips — while living inside the core distribution, so there’s nothing to install and no workflow to abandon. It won’t replace jj’s operation log, undo, or working-copy-as-commit model, but it lowers the barrier to the specific ergonomics that draw people to jj in the first place.