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.

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`.

I think you'll find your workflow is still required. `git history split` is really only focused on turning a commit into 2 commits, so if you wanted multiple, you would need to run the command multiple times.

Add to that, it's patch functionality isn't as robust as `git add --patch`. For example, you cannot edit a hunk, so if you intended to tease out atomic changes, you won't be able to.

I do the same, but use `git gui` to select the changes.