It's not that roundabout compared to what `git history split` is doing. It's sort of the missing tool in a lot of the rebase discussions (in the Stack Overflow answers). Basically `git history split` is most useful for "split an older commit in this branch", so it's a higher level complex dance of, essentially:

- `git rebase -i`

- Change the TODO list to `edit` the chosen commit (everything else to `pick`)

- At the `edit` point:

  - (simplified) `git add -p`

  - `git commit`

  - `git add -u`

  - `git commit`

That "simplified" `git add -p` in the middle and that assumption that everything else not selected is the "other patch" is fine for quick splits, but there's still power user super powers in knowing the full rebase workflow and `git add -p`.

This is nicely documented but seems to be missing the `git reset HEAD^` when rebase drops you into editing the marked commit.