logoalt Hacker News

kccqzyyesterday at 10:19 PM4 repliesview on HN

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.


Replies

Espressosaurustoday at 7:58 AM

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.

Mashimotoday at 7:26 AM

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.

fingerlocksyesterday at 11:05 PM

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

show 1 reply
imrontoday at 4:08 AM

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