From: D. Ben Knoble Date: Tue, 02 Dec 2025 22:44:15 GMT Subject: Re: [PATCH v6 04/11] builtin: add new "history" command Message-ID: In-Reply-To: On Tue, Dec 2, 2025 at 1:48 PM Patrick Steinhardt 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 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