Splitting a Git Commit

It seems strangely polarizing to refer to the "old and cumbersome" interactive rebase approach in contrast to "the right approach" using `git history` which is a brand new, experimental feature as of Git 2.54 from April 20, 2026, a few months ago.

I have split a lot of work with interactive rebasing. I'm excited to try `git history split` and to have learned about it here. But the stylistic flourish makes it seem like it's been a feature for years that people just haven't moved to instead of being something shiny and new to be excited about trying.

This is a relatively recent feature. I was first introduced to it in GitHub's release notes for Git 2.54:

https://github.blog/open-source/git/highlights-from-git-2-54...

And discussion at the time:

https://news.ycombinator.com/item?id=47837698

> P.S. The stack overflow question for splitting commits discusses the old and cumbersome approach. The 20th answer discusses the right approach but has a meagre 2 upvotes as of today, compared to 2656 for the older top answer with the cumbersome approach.

It now has 5 upvotes. A long way to go to 2656 but at least it's going in the right direction.

That's good to know, I'd usually go about it in a roundabout way: soft reset the commit then git add --patch to stage the hunks to split it into multiple commits.

In case you're curious if _you_ can run `git history split`, the answer is almost certainly no, unless you manually installed the newest release of Git within the last 3 months.

`git history` was introduced as an experimental command less than 4 months ago, which means that there are essentially zero OS releases that packages a version that contains it by default. Also, if you're on OSX and run `brew install git`, it will not overwrite the Apple version that is too old to have it.

Git 2.54 was the first release with this subcommand and it is not in Xcode CLT, Debian testing, Ubuntu 26.04 - nothing. It will be "normal" in a year, but it's ridiculous to criticize SO for "old" methods of splitting long before anyone ships with it.

or use jj and stop worrying about git

jj split --interactive {ref}

StackOverflow is really not great at handling questions for which the right answer changes over time. I guess it doesn't matter since SO is dead anyway: https://news.ycombinator.com/item?id=46482345

The SO upvote problem is real. Once an answer hits a few hundred votes, nobody scrolls past it to check if something better came along.

Ostensibly elite is always the way to go.

Today I learned about git history split. Thanks!!

I’m doing rebasing a lot these days, especially since I started using gh stack. The main struggle I have with rebasing is for git to recognize that a branch has actually been merged when its commits have changed (e.g., if I forgot to delete the local branch with old commits and come back months later and trying to figure out if it was actually merged or not). My understanding is that this is nicer with jj when you work locally, but if you sync with GitHub, I think your still faced with the same problem, or?

What are people doing to workaround this? I’ve tried to ask LLMs, but the complexity is frankly a bit off putting (I don’t have the suggestions handy)

I never thought about whether this was possible, but now that I know it is, I immediately see how useful it could be for my workflow.

Love the minimalist blog layout

I think I'd rather keep my old school interactive rebase skills sharp for when I actually need it

Is this yet another case of git improving its UI due to jujutsu?

(This is exactly how jj does it.)

If you like this kind of convenient CLI command, I would seriously recommend giving jj a try. To give you an idea, I never bothered splitting a commit in my git days. I do it almost daily with jj. Lots of other niceties that I didn't bother with in git, but routinely do in jj.

jj has fewer commands than git, yet does everything git does.

The bit that made this click for me: it works on any commit in history, not just HEAD. Mark the commit as edit in git rebase -i, then git reset HEAD^ to uncommit it while keeping the changes in the working tree, and rebuild the pieces from there.

git add -p is the real workhorse for the rebuild: s splits a hunk into smaller ones, and e lets you hand-edit the hunk when the boundary doesn't fall on clean line breaks. Stage a coherent slice, git commit, repeat until the tree is empty, then git rebase --continue. The rebase's only job is to drop you at the right spot; add -p does the actual splitting.