Subject: Re: [PATCH RFC v2 15/16] builtin/history: implement "split" subcommand

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 3 Sep 2025 14:20:00 +0200

On Sun, Aug 24, 2025 at 08:03:18PM +0200, Kristoffer Haugsbakk wrote:
> On Sun, Aug 24, 2025, at 19:42, Patrick Steinhardt wrote:
> > This is quite complex, and overall I would claim that most people who
> > are not experts in Git would struggle with this flow.
> >
> > Introduce a new "split" subcommand for git-history(1) to make this way
> > easier. All the user needs to do is to say `git history split $COMMIT`.
> > From hereon, Git asks the user which parts of the commit shall be moved
> > out into a separate commit and, once done, asks the user for the commit
> > message. Git then creates that split-out commit and applies the original
> > commit on top of it.
> 
> The interactive mode here seems just-right.
> 
> • Split in two, give the commit message for the new one
> • I can use `git history split :/'The second batch'` if I want to split
>   a single commit multiple times
> • I can use `git history reword :/'The second batch'` if I want
>   to change the original commit message as well
> 
> But it’s interactive-only, correct?  Would it make sense for a stateful
> split session so that other tools could be used to split the patch?

Yeah, it's interactive-only. I see git-history(1) as part of porcelain
rather than plumbing, so this is kind of intentional. I also wouldn't
quite know how this would look like to have a split session.

But if anyone has an idea how such a stateful split session might look
like I don't see a strong reason to not add this in the future. For now
though my focus is to get a baseline going that helps the user to
perform common tasks easier as opposed to before.

Patrick