From: D. Ben Knoble Date: Wed, 07 Jan 2026 17:39:47 GMT Subject: Re: [PATCH v8 0/7] Introduce git-history(1) command for easy history editing Message-ID: In-Reply-To: <20260107-b4-pks-history-builtin-v8-0-18e9779e3a26@pks.im> On Wed, Jan 7, 2026 at 5:10 AM Patrick Steinhardt 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" ;) > + is a need that users have. While rebases _can_ serve this use case if > + one always works on the latest stacked branch, it is somewhat awkward > + and very easy to get wrong. > + > + Add a new "history" command to plug these gaps. This command will have > several different subcommands to imperatively rewrite history for common > - use cases like the above. Some of these subcommands will be implemented > - in subsequent commits. > + use cases like the above. > > Signed-off-by: Patrick Steinhardt > > @@ Documentation/git-history.adoc (new) > + > +NAME > +---- > -+git-history - EXPERIMENTAL: Rewrite history of the current branch > ++git-history - EXPERIMENTAL: Rewrite history > + > +SYNOPSIS > +-------- > @@ Documentation/git-history.adoc (new) [snip] > ++If you want to reapply a range of commits onto a different base, or interactive > ++rebases if you want to edit a range of commits. Hm? This feels incomplete to me. Best, Ben