Hi

As soon as I saw the announcement of 'git history', I knew that was something I was gonna use a lot. Especially the split functionality has always been somewhat of a hassle (at least for me) to do via an interactive rebase. I've played around with it a little, and it seems to work as it says on the tin.

So today I had occasion to put it to real use, and then I found two things I'd like to be able to do with it:

When a commit needs to be split into three or more commits, it is a little cumbersome to do iteratively, since the new commit to split obviously has a new sha, so one first has to figure out what that new id is and then do another "git history split". For higher values of "three" that becomes rather tedious. So it would be nice if there was an iterative mode, which after splitting off the first commit would automatically start again with the new child commit.

If "git add -p" had an answer meaning "yes to this hunk and all following in this file and all remaining files as well", this could probably even be the default behaviour of "git history split", as it would just require that one extra answer to be given after the first commit is split off in order to keep the current behaviour. Otherwise, I'd also be happy to have "git history iter-split" or "git history split --iter" or any other spelling.

The other thing I'd like is a sort of ultimate version of the above: What I needed in the concrete case at hand was actually to split two commit into n individual hunks each, then do an interactive rebase to combine those 2n commits to n commits (I had done changes "row-wise", but needed to change them to "column-wise"). For that, I would like to have had a completely automatic "git history atomize" that would split a commit into individual hunks, prefixing the commit subject with e.g. "[<filename> -- hunk #nn]". A subsequent 'git rebase -i' could then easily rearrange those and squash the related hunks.

Aside: are experimental commands eligible for teaching the completion
logic about them? I.e., can we add a __git_history() to
git-completion.bash? Aside from the obvious "let it know about existing
subcommands", I'd love for "git history split <TAB>" to show the most
recent ~20 (or something) commits in one-line format, stopping if
there's a merge commit.

Thanks, Rasmus

On Thu, Jun 04, 2026 at 10:17:07AM +0200, Rasmus Villemoes wrote:

Happy to hear!

That's fair, and also something that was discussed when initially introducing the "split" subcommand. We don't have that mode right now, but I think it would make sense to maybe add a new option that makes us split repeatedly until all chunks have been exploded into separate commits.

Yeah. From my perspective, having this available as an option would be the best path forward. But I'm also open to alternatives as you suggest.

It could easily be another option: `git history split --explode` for example, which seems to be a common term for such an operation.

Regarding the subsequent rebase: I have one more patch series cooking locally that implements `git history move` to move around commits, and I did have the plan to eventually also implement `git history squash` to squash commit A into commit B. But when handling many commits it might even be easier to use interactive rebases instead.

Well, unless we eventually maybe even get something like a graphical interface. I was playing around with a TUI interface for git-history(1) that lets you move commits around without the hassle of the command line. But that's certainly something that's still going to take a while to materialize, if it ever does.

I just haven't gotten around to it yet. I'd certainly welcome the addition of command line completion.

Thanks for your feedback!

Patrick

On Thu, Jun 4, 2026, at 10:17, Rasmus Villemoes wrote:

For commit subject `anchor` I would do something like this.

1. `git history split :/anchor`
2. Split out the first commit with a new message; keep the `anchor`
   subject of the original
3. Repeat (1)