Re: [PATCH v4 12/12] builtin/history: implement "split" subcommand

> On Tue, Oct 21, 2025 at 7:44 AM Patrick Steinhardt <ps@pks.im> wrote:
> > On Tue, Oct 14, 2025 at 09:38:51AM -0400, Karthik Nayak wrote:
> > > Patrick Steinhardt <ps@pks.im> writes:
> > > > diff --git a/Documentation/git-history.adoc b/Documentation/git-history.adoc
> > > > index b55babe206..83d675afea 100644
> > > > --- a/Documentation/git-history.adoc
> > > > +++ b/Documentation/git-history.adoc
> > > > @@ -40,6 +41,26 @@ rewrite history in different ways:
> > > >     provided, then this command will spawn an editor with the current
> > > >     message of that commit.
> > > >
> > > > +`split [--message=<message>] <commit> [--] [<pathspec>...]`::
> > > > +   Interactively split up <commit> into two commits by choosing
> > > > +   hunks introduced by it that will be moved into the new split-out
> > > > +   commit. These hunks will then be written into a new commit that
> > > > +   becomes the parent of the previous commit. The original commit
> > > > +   stays intact, except that its parent will be the newly split-out
> > > > +   commit.
> > > >
> > >
> > > So in essence we do this:
> > >
> > >   Before split:
> > >   P1 ── C0 ── C1 ── ... ── CN
> > >         └─(target)         └─(HEAD)
> > >
> > >   After split:
> > >   P1 ── S0 ── C0' ── C1 ── ...... ── CN
> > >         │     └─(modified original)  └─(HEAD)
> > >         └─(split-out hunks)
> > >
> > > I do wonder if S0 should contain the existing message and the new
> > > message should go to C0'. So perhaps more like
> > >
> > >   After split:
> > >   P1 ── C0' ── S0 ── C1 ── ..... ── CN
> > >         │      └─(split-out hunks)  └─(HEAD)
> > >         └─(modified original)
> > >
> > > Mostly because when you say split, I would assume we keep the original
> > > as is and add on top of it. I don't really have a strong argument though
> > > :)
> >
> > Yeah, this has already caused some discussion beforehand. I guess you
> > can argue either way, and the suggestion from others was to simply allow
> > the user to edit both commit messages.
> >
> > I don't at all mind going into that direction, but I wonder how to call
> > the "--message" switch in that case. We could of course just call these
> > "--first-message" and "--second-message", but that feels somewhat
> > awkward.
> >
> > Also, I already have it in my mind that it would be cool to extend this
> > command so that you can split into arbitrary many commits. That is,
> > after you have split out the first commit we simply go back into
> > interactive mode to create a second commit tree. Rinse and repeat until
> > we have no chunks left anymore. But if we had such a mode though, then
> > numbered parameters don't make much sense anymore.
> >
> > An alternative could be to just accept multiple "-m" arguments, and we
> > then apply the messages to the respective commits? Dunno.
> 
> Or *gasp* not support "-m" at all, and require the user to put
> _something_ in an editor? 🤔