From: Patrick Steinhardt Date: Fri, 09 Jan 2026 07:34:12 GMT Subject: Re: [PATCH v8 0/7] Introduce git-history(1) command for easy history editing Message-ID: In-Reply-To: On Wed, Jan 07, 2026 at 12:39:47PM -0500, D. Ben Knoble wrote: > 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! We only have "reword" for now. In any case, I'll definitely upstream more subcommands once the initial version has landed. Probably the complete set of commands I was proposing initially: "drop", "split" and "reorder". Afterwards I'd also like to have a look at "absorb", but I'll also gladly accept any help. > > 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" ;) Fixed both, thanks! Patrick