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

> On Tue, Dec 2, 2025 at 1:48 PM Patrick Steinhardt <ps@pks.im> 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 <ps@pks.im> 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.