Not sure if this is written by an AI, but I'll engage, because it's a bit misleading.

The new `git history` command can take three verbs - fixup, reword and split. While interactive rebasing can do fixup and rewording relatively easily and the `history` variant is a slight improvement, the split sub-subcommand is really _quite_ difficult to do in other Git tooling, including interactive rebase. Before reading on, I would challenge the reader to think about how they might do it.

The answer is that you would rebase back to at least the commit you're splitting, choose 'edit' in the rebase script for that commit (pick the rest), then when the rebase stops there, `git add (-p)` the parts you want, commit, then commit the rest, then `git rebase --continue`. I would guess that maybe 5% of the readers of this paragraph would have guessed that correctly, if I'm being pretty positive.

Patrick wrote the `git history` stuff because tools like JJ and GitButler are pushing UX that makes this type of thing very easy and Git itself is struggling to catch up. Even at a fundamental level, the first versions of history were based on the sequencer code that rebase used but it couldn't do the job properly (messing with the index/workdir), so he rewrote it based on the `git replay` machinery instead (which _itself_ is still somewhat experimental).

Interestingly, it's _still_ not optimized for agents or scripting - `split` specifically needs an interactive terminal like `git add -p` does, so not many agents are good at it. I recently tried it and Claude piped `y\ny\nn` through the command, guessing at the interactive input (y, y, n) needed to stage the hunks.

The point is, interactive rebasing is a horrible solution to this problem, `git history` clearly better, at least for splitting, but really we need non-interactive solutions to problems like this so agents can do them well.

GitButler does this well because we focus specifically on it - our status command gives hunks/files ids and hunk/file movement can happen between commits so splitting is creating an empty commit and then moving the parts over - but it's surprising that nobody else builds tooling for this increasingly common use case.

I think `git history` will slowly get better at this over time, but "interactive rebasing" is a _much_ more error prone and unintuitive way to accomplish this.

> The point is, interactive rebasing is a horrible solution to this problem, `git history` clearly better, at least for splitting, but really we need non-interactive solutions to problems like this so agents can do them well

If it’s for scripting why not use the lower level ‘git update-index’. Start from the original file and a patch filed, edit the patch, apply it, and then add it the modified file to the index. The patch is the container of changes in my opinion, better have the agent act on that and then apply it instead of working interactively with the work tree.