Re: [PATCH 8/8] builtin/history: implement "split" subcommand
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Mar 11, 2026, 09:26 UTC
- Message-ID
- <abE1PPWRdPaHMaAs@pks.im>
- In-Reply-To
- <CALnO6CC_UMnQvcyCe37mCan8eASugknK-WbVp-KWXWptvrsJDg@mail.gmail.com>
On Tue, Mar 03, 2026 at 01:47:27PM -0500, D. Ben Knoble wrote:
Show 39 quoted lines
> 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