[kccqzy]

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.

[fingerlocks]

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

[kccqzy]

Okay so the same operation with git is an esoteric flag but it’s easy in mercurial. Got it. Which has the better UX then?

> It’s trivial to separate that result into two or more steps

Okay first, tell me how to separate it into two or more steps. Second, tell me why a single operation in a user’s mental model needs to be split into two commands. The user is thinking about moving a commit and its descendants from one place to another; why should this seemingly atomic operation be split.

[imron]

> 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) ;-)

[Mashimo]

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.

[kccqzy]

Incredibly common when you write code faster than your colleague or manager can review them. You always have lots of branches and sometimes the branches implement interrelated functionality.

[Mashimo]

Interesting. Why not keep on a merge branch before review?

[Espressosaurus]

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.