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.
