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

>
> 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).

> 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

>     +    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 <ps@pks.im>
>
>     @@ 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)