I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto).
In contrast every single mercurial user I know can intuitively use `hg rebase` with its `-s` and `-d` flags. That’s one giant difference in UX.
Is that a common usecase?
I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.
You need to say “ i’ve never met anyone who could do that in one single command line invocation”. It’s trivial to separate that result into two or more steps using bare primitive git commands and perhaps a temporary branch. You don’t need to memorize every esoteric flag if you understand the fundamentals and don’t mind spending 15 extra seconds to execute multiple commands
> This requires using the extremely unintuitive `git rebase --onto A B C` invocation.
Unintuitive yes, and I'm not going to disagree with you on UX, but it's not a particularly difficult thing to learn if you use a rebase centric workflow and this is a command I use daily.
P.S. don't forget to use --update-refs (or add to your .gitconfig) ;-)
And if you don't know the syntax off the top of your head, as long as you know the verb you can find out what it is.