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

From: Sergey Organov <[email-masked]>
Date: Thu, 21 Aug 2025 19:26:57 +0300

Junio C Hamano <[email-masked]> writes:

> Patrick Steinhardt <[email-masked]> writes:
>
>> 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.
>>
>> Note: This patch series currently builds on the cherry-pick infra.
>> As such, when one hits a merge conflict one needs to `git cherry-pick
>> --continue`, which is quite suboptimal. I didn't want to overpolish this
>> series before getting some feedback, but it is something I'll fix in
>> subsequent versions. Furthermore, the command for now bails out in the
>> case where there's any merge commits in the history that is being
>> rewritten. This is another restriction that can be lifted in the future.
>
> Two comments.
>
>  - You would want to honor notes.rewriteref yourself, as cherry-pick
>    does not and that is deliberate [*].
>
>  - It is a sensible design decision to limit it to linear single
>    strand of pearls history.  "history reword <commit>" when
>    <commit> can be reached from many branches along linear history
>    that rewrites all these commits on these branches would be handy.
>    There may need some way to say "these branches are protected, if
>    'history reword <commit>' needs to touch commits on any of these,
>    abort" and things like that.
>
>
> [Footnote]
>
>  * "history edit" (aka "rebase") is an operation that "edits" the
>    history, once the edit finishes, the result is *the* history you
>    want, and the previous one is to be discarded (except for in
>    reflog).  "cherry-pick" on the other hand is "I have this good
>    thing on this development track, I want an equivalent _copy_ of
>    it on _another_ track"---it merely is an easier and quicker way
>    than typing the same thing yourself on top of the other track,
>    and does not duplicate notes.

Unless I'm ignorant, "git rebase" (aka "history edit") lacks essential
feature though: in addition to saying: get "this" history and rebase it
"there", one should be able to say: get "that" history, and rebase it
"here" (aka cherry-pick on steroids), that also would eliminate the need
for 'git cherry-pick <range>' that (poorly) duplicates rebase
functionality.

If not to implement this as, say, "git rebase --pick", I'd like to see
this feature in the new "git history" command, but then it'd eventually
become yet another "git rebase"? Or will Git then aim to eventually
factor-out a lot of "git rebase" functionality into new "git history
rebase <what> <where>", or something like this?

Thanks,
Sergey Organov