On Sun, Aug 24, 2025, at 19:42, 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 of it into a separate commit. This is quite an involved operation s/out of it into/out into/ > 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. Exactly right and this fills a conspicuous hole (in the rewriting parts of git(1)). > > 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? One nice thing about “the staging area” is that people can use whatever tools they want for things like selectively including changes in a commit. Likewise for a rebase session.
