Re: [PATCH RFC v3 17/18] builtin/history: implement "split" subcommand

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 15, 2025, 09:32 UTC
Message-ID: <aMfdR3JE4zq-2j9b@pks.im>
In-Reply-To: <51689153-3012-4d3c-995b-69af296ea608@gmail.com>

On Wed, Sep 10, 2025 at 03:04:49PM +0100, Phillip Wood wrote:

Show 39 quoted lines

> On 04/09/2025 15:27, Patrick Steinhardt wrote:
> > It is quite a common use case that one wants to split up one commit into
> > multiple commits by moving parts of the changes of the original commit
> > out into a separate commit. This is quite an involved operation though:
> > 
> >    1. Identify the commit in question that is to be dropped.
> > 
> >    2. Perform an interactive rebase on top of that commit's parent.
> > 
> >    3. Modify the instruction sheet to "edit" the commit that is to be
> >       split up.
> > 
> >    4. Drop the commit via "git reset HEAD~".
> > 
> >    5. Stage changes that should go into the first commit and commit it.
> > 
> >    6. Stage changes that should go into the second commit and commit it.
> > 
> >    7. Finalize the rebase.
> > 
> > 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.
> 
> I like the idea of this command, but I think it would be much better to
> prompt the user to edit the orginal message after creating each new commit
> rather than asking them to write a new message for the first commit that we
> create and then not letting them edit the message for the second commit.
> We've got no way of knowing how they are splitting the commit - they could
> be keeping most of the canges from the orginial in the first commit in which
> case they probably want something simiar to the orginial commit message for
> that one, or, they could be spitting out something which means they need to
> edit the message when creating the second commit.

Yeah, Junio already said the same. I can do that.

> If this was implemented in the sequencer then we'd be able to reuse the
> existing code for creating commits and editing commit messages. It would
> also make the "split" command available to "rebase -i".

True, having it available in "rebase -i" would be nice indeed.

Patrick