Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing

[Patrick Steinhardt <ps@pks.im>]

On Sat, Aug 23, 2025 at 06:25:06PM -0700, Martin von Zweigbergk wrote:
> On Tue, Aug 19, 2025 at 3:57 AM Patrick Steinhardt <ps@pks.im> 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.
> 
> It also rebases all descendants on top of the parent(s) of the
> abandoned commit(s). Branches pointing to the rebased commits are also
> repointed. So is the working copy if it points to a rebased commit
> (the closest equivalent in Git would be HEAD). Do you plan to make all
> the `git history` commands behave that way too?

Yup.

[snip]
> >   - `git history reorder` to reorder a specific commit before or after
> >     another commit. This is inspired by jj-new(1).
> 
> It seems more similar to `jj rebase -r X -A/-B Y`, which rips X out of
> the graph and inserts it after/before Y. Just FYI; I'm not asking for
> any changes.

Fair enough. I think calling this `git history rebase` would be
problematic though given that "rebase" is already a widely used term in
Git that means something else.

> >   - `git history split` takes a commit and splits it into two. This is
> >     basically the same as jj-split(1).
> 
> FYI, the default behavior of `jj split` is to split the commit into
> parent and child, but there's also `-A/-B X` to take the selected
> changes and insert them after/before X, or `-d X` to put them on top
> of X.

Oh, that's neat and I can totally see how that is useful. I'll not yet
add such a change, but that's certainly something we can add at a later
point in time rather easily.

> > 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.
> 
> FYI, `jj describe` can also change the commit message of multiple
> commits at once (e.g. `jj describe main..@` to edit your current chain
> of commits). It concatenates each description with some separators
> between in that case so you can update them all at once in your
> $EDITOR.
> 
> I'm letting you know these things in case it impacts planning for the
> CLI arguments.

And I very much appreciate it :) A bunch of the functionality in Git
will have different terminology so that it fits better into Git overall.
There for example is already the "reword" action in the interactive
rebase code, so it makes sense to keep on using it. Same for "drop", for
example.

> >   - `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.
> 
> Perhaps the simplest thing to copy is revsets (which we copied from
> Mercurial). See https://jj-vcs.github.io/jj/latest/revsets/. It's not
> at all simple to implement, but I think it should be relatively simple
> from a UX point of view because it can probably be done in a mostly
> backwards compatible way.

True, I very much like the way revsets work in JJ. Whether it can be
used in a backwards-compatible way... no idea. I'd have to think about
this more closely, but for now I think there's other, lower-hanging
fruit :)

Patrick