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

[Sergey Organov <sorganov@gmail.com>]

Ben Knoble <ben.knoble@gmail.com> writes:

>> Le 21 août 2025 à 12:51, Sergey Organov <sorganov@gmail.com> a écrit :
>> 
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>>> Patrick Steinhardt <ps@pks.im> 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.
>
> But isn’t that
>
>     git rebase --onto=<here> <that-upstream> <that>

Cause we end-up being on modified <that> (unless my memory fails me)
rather than on modified <here> when intent is to keep <that> intact.

> ? And why is that cherry-picking a range is a poor substitute [it is
> rather rebase that duplicates cherry-pick ;)]?

Because rebase has a lot of useful features compared to cherry-pick,
such as --interactive, --exec, merges handling, etc. In fact, IMHO,
"cherry-pick" should better be Git plumbing, and every-day-user-needs
should be handled by "rebase".

Historically, when ranges support was added to "cherry-pick", it was
probably a mistake, as "rebase" appears to be a better place for needed
functionality, and what was needed is rather adding "--pick" support to
"rebase".

-- 
Sergey Organov