On Sat, Aug 18, 2018 at 3:50 PM Jonathan Nieder <[email protected]> wrote: > (cc-ing Elijah Newren for the points about merging)
> [...] > > Git doesn't provide a low-level command to rebase a branch onto > > another without touching the index. > > Thanks for pointing this out. There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. See https://crbug.com/git/12 for some references. > There's also been some heavy refactoring of "git rebase" code to be in > C and be able to make use of library functions instead of being a > shell script. > > That's all to say that we're in a pretty good place to consider > introducing commands like > > git cherry-pick --onto=<branch> <revisions> Yes, indeed, after the merge refactoring/rewriting stuff is complete, this is one thing already on my list that I wanted to do with it. Another thing I'd like to investigate with it is how much "in-memory" merges could speed up interactive rebases, as suggested by Dscho[1]. Once we do "in-memory" merges for interactive rebases for performance reasons, we're pretty close to having a rebase-without-touching-index-or-worktree that we can make accessible to other scripts like git-bug. However, we have to have a pretty good answer about what to do when we hit conflicts. [1] https://public-inbox.org/git/[email protected]/
