Ben Knoble <ben.knoble@xxxxxxxxx> writes: >> 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> 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
