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

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Dec 2, 2025, 22:44 UTC
Message-ID: <CALnO6CDG5EMha8k4DPy=p0FT1hO_SeU0wxm6qn2+Q92xNY6hqQ@mail.gmail.com>
In-Reply-To: <aS80co7VTABD6nXs@pks.im>

On Tue, Dec 2, 2025 at 1:48 PM Patrick Steinhardt <ps@pks.im> wrote:

Show 37 quoted lines

>
> 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.

-- 
D. Ben Knoble