Re: [PATCH v8 0/7] Introduce git-history(1) command for easy history editing

> On Wed, Jan 7, 2026 at 5:10 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.
> 
> > - I've dropped the patches introducing `git history split` and will
> >   send this as a follow-up patch series once this once has been
> >   merged. This was done to focus attention on the underlying mechanics
> >   as much as possible (and to keep my own sanity with the frequent
> >   revamps).
> 
> Sane, if sad for my custom build which has enjoyed having "git history" commands
> available :) I can wait for other patches, or try to contribute some, though.
> 
> [reads further]
> 
> Oh, it's just split that drops; we still have reword, etc. Cool!

> > Range-diff versus v7:
> >
> >  -:  ---------- >  1:  53a845e874 builtin/replay: extract core logic to replay revisions
> >  -:  ---------- >  2:  3ff1c0bacf builtin/replay: move core logic into "libgit.a"
> >  -:  ---------- >  3:  598df4e186 replay: small set of cleanups
> >  -:  ---------- >  4:  fd6a0ec5b8 replay: yield the object ID of the final rewritten commit
> >  1:  0e2d8db69f =  5:  04b832320f wt-status: provide function to expose status for trees
> >  2:  087c563575 <  -:  ---------- replay: extract logic to pick commits
> >  3:  4ab2a6f807 <  -:  ---------- replay: stop using `the_repository`
> >  4:  d2138e95d4 !  6:  e223659b86 builtin: add new "history" command
> >     @@ Commit message
> >
> >          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
> >     +    one wants, and then perform the actions. Also, 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
> >     +    Another problem that rebases have is that dependent branches are not
> >     +    being updated. The use of stacked branches has grown quite common with
> 
> "[D]ependent branches are not being updated" reads weirdly to me.
> "Rebases also do not update dependent branches" perhaps?
> 
> >     +    competiting version control systems like Jujutsu though, so it clearly
> 
> "competing" ;)