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