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

[Patrick Steinhardt <ps@pks.im>]

On Tue, Mar 03, 2026 at 01:47:27PM -0500, D. Ben Knoble wrote:
> On Mon, Mar 2, 2026 at 7:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> > diff --git a/Documentation/git-history.adoc b/Documentation/git-history.adoc
> > index cc019de697..24dc907033 100644
> > --- a/Documentation/git-history.adoc
> > +++ b/Documentation/git-history.adoc
> > @@ -57,6 +58,26 @@ The following commands are available to rewrite history in different ways:
> >         details of this commit remain unchanged. This command will spawn an
> >         editor with the current message of that commit.
> >
> > +`split <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.
> > ++
> > +The commit messages of the split-up commits will be asked for by launching
> > +the configured editor. Authorship of the commit will be the same as for the
> > +original commit.
> > ++
> > +If passed, _<pathspec>_ can be used to limit which changes shall be split out
> > +of the original commit. Files not matching any of the pathspecs will remain
> > +part of the original commit. For more details, see the 'pathspec' entry in
> > +linkgit:gitglossary[7].
> 
> That is quite convenient when changes to 2 independent areas have
> become mixed. Nice.
> 
> > +It is invalid to select either all or no hunks, as that would lead to
> > +one of the commits becoming empty.
> 
> Is it easy to make this a no-op? It could be done later if that
> suggestion is contentions. But I figure rather than error we can
> silently do nothing, since we have performed the desired split. (Or
> even use this to split an "--allow-empty" commit, but… why that's
> desirable, I can't guess.)
> 
> So yeah, probably for later.

I mean we could make it a no-op, but wouldn't that make the interface
even more confusing? You don't really split a commit in the case where
you select everything or nothing, as you'd only end up with a single
commit in that case. Making one of the commits completely empty would
probably be an accident in almost all cases, I would claim.

But yeah, if there actually are use cases for this I would say that we
could then introduce "--allow-empty" for this command at a later point.

Patrick