On Thu, Sep 4, 2025 at 11:43 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > 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. Cool, I had been thinking of adding some jj-like functionality as well, to git-replay in my case, though I was more interested in fixing up the infrastructure to handle replaying merges sanely first. > 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. So, this brings up a question. Should we have git-rebase & git-cherry-pick & git-replay & git-history, or should we consolidate? I had envisioned having git-replay consolidate both cherry-pick and rebase functionality into one (then got pulled away by combination of work reassgniment & multiple life crises hitting at once taking my focus away for quite some time). But now we're going in the other direction. And further along that other direction is another extreme -- just having these be top-level commands, e.g. "git reorder", "git split", etc. In a separate conversation we had (and I hope I'm paraphrasing correctly; if not please correct me), you mentioned you wanted git-history to be the home of history rewriting, and viewed git-replay as just a server side thing (whereas I created git-replay specifically as a user-focusing thing and then Christian changed it into a server-side thing since that part was complete and enough for his purposes). But if git history is the home of history editing, how far does that go? Do we have a "git history reset"? "git history commit"? "git history fast-export/fast-import" "git history filter-repo"? Or is it just the home for certain kinds of history rewriting operations? If so, which ones? That all said, I'm a big fan of the idea of incorporating more of jj capabilities, and you clearly marked the command as experimental (thanks!), which leave us room to adjust later if we don't like this path. So I don't want to serve as a roadblock, I just think it's a useful conversation to have...
