Subject: Re: [PATCH v6 04/11] builtin: add new "history" command

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 3 Dec 2025 11:48:15 +0100

On Tue, Dec 02, 2025 at 05:44:15PM -0500, D. Ben Knoble wrote:
> On Tue, Dec 2, 2025 at 1:48 PM Patrick Steinhardt <[email-masked]> wrote:
> >
> > On Wed, Nov 19, 2025 at 11:02:20PM -0800, Elijah Newren wrote:
> > > In addition to what Phillip commented on...
> > >
> > > On Mon, Oct 27, 2025 at 4:34 AM Patrick Steinhardt <[email-masked]> wrote:
> > > >
> > > > When rewriting history via git-rebase(1) there are a couple of very
> > > > common use cases:
> > > >
> > > >   - The ordering of two commits should be reversed.
> > > >
> > > >   - A commit should be split up into two commits.
> > > >
> > > >   - A commit should be dropped from the history completely.
> > > >
> > > >   - Multiple commits should be squashed into one.
> > > >
> > > > While these operations are all doable, it often feels needlessly kludgey
> > > > to do so by doing an interactive rebase, using the editor to say what
> > > > one wants, and then perform the actions. Furthermore, some operations
> > > > like splitting up a commit into two are way more involved than that and
> > > > require a whole series of commands.
> > > >
> > > > Add a new "history" command to plug this gap. This command will have
> > > > several different subcommands to imperatively rewrite history for common
> > > > use cases like the above. These subcommands will be implemented in
> > > > subsequent commits.
> > >
> > > "...*Some of* these subcommands will be implemented...", right?  You
> > > only implement two of them in this series, not all of them, or am I
> > > reading wrong?
> >
> > No, you're right. The initial versions of this series implemented more
> > of the above commands, but at no point in time did we actually implement
> > all of them.
> >
> > Patrick
> 
> While I'm thinking of it, at work today I had occasion to use "drop"
> and "reorder" (from an old version of this series whose binary I
> happened to still have laying around), and it was very convenient.
> Looking forward to it ;)
> 
> - drop: I had made some changes on my tree that needed to be in a
> separate branch. I didn't want to mess with stashes for some reason,
> so I did "commit; switch -c …; cherry-pick @@{1}" (or something
> similar). Then when coming back (switch -), I could just do "drop @".
> I'm sure there's a better way to do this slicing that wouldn't have
> needed drop, but I couldn't think of it at the time.
> 
> - reorder: I have a series of mostly logical, separate wip commits
> that need some more explanation and might need further tweaks as I go;
> I'm working on uncommitted changes that logically belong to the tip,
> but spot something else that will be a separate commit. I make that
> commit, then "reorder @ --before-commit=@~", and voilà, I'm ready to
> amend again when I get around to committing the rest of what I have.

Yeah, I definitely do wish to also upstream these two going forward.
It's going to be a bit more complicated though now that we are building
on top of the replay infrastructure, because it doesn't know to handle
conflicts.

Maybe for an initial version we can get away with just bailing out on a
conflict and then iterate.

Patrick