> Le 21 août 2025 à 12:51, Sergey Organov <sorganov@xxxxxxxxx> a écrit :
>
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Patrick Steinhardt <ps@xxxxxx> 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>
? And why is that cherry-picking a range is a poor substitute [it is rather rebase that duplicates cherry-pick ;)]?
