Introduce git-history(1) command for easy history editing

Hi,

over recent months I've been playing around with Jujutsu quite frequently. While I still prefer using Git, there's been a couple features in it that I really like and that I'd like to have in Git, as well.

A copule of these features relate to history editing. Most importantly, I really dig the following commands:

• jj-abandon(1) to drop a specific commit from your history.

• jj-absorb(1) to take some changes and automatically apply them to commits in your history that last modified the respective hunks.

• jj-split(1) to split a commit into two.

• jj-new(1) to insert a new commit after or before a specific other commit.

Not all of these commands can be ported directly into Git. jj-new(1) for example doesn't really make a ton of sense for us, I'd claim. But some of these commands do make sense.

I thus had a look at implementing some of these commands in Git itself, where the result is this patch series. Specifically, the following commands are introduced by this patch series:

• git history drop to drop a specific commit. This is basically the same as jj-abandon(1).

• git history reorder to reorder a specific commit before or after another commit. This is inspired by jj-new(1).

• git history split takes a commit and splits it into two. This is basically the same as jj-split(1).

If this is something we want to have I think it'd be just a starting point. There's other commands that I think are quite common and that might make sense to introduce eventually:

• An equivalent to jj-absorb(1) would be awesome to have.

• git history reword to change only the commit message of a specific commit.

• git history squash to squash together multiple commits into one.

In the end, I'd like us to learn from what people like about Jujutsu and apply those learnings to Git. We won't be able to apply all learnings from Jujutsu, as the workflow is quite different there due to the lack of the index. But other things we certainly can apply to Git directly.

Note: This patch series currently builds on the cherry-pick infra. As such, when one hits a merge conflict one needs to git cherry-pick --continue, which is quite suboptimal. I didn't want to overpolish this series before getting some feedback, but it is something I'll fix in subsequent versions.

Thanks!

Patrick

To: git@vger.kernel.org

--- b4-submit-tracking ---

This section is used internally by b4 prep for tracking purposes.

{ "series": { "revision": 1, "change-id": "20250819-b4-pks-history-builtin-83398f9a05f0", "prefixes": [] } }