2 ms·

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 `g

by kccqzy 5mo ago

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 5mo ago
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 5mo ago
  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 5mo ago
> 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 5mo ago
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 5mo ago
  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 5mo ago
    Interesting. Why not keep on a merge branch before review?
Espressosaurus 5mo ago
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.

by kccqzy 5mo ago

fingerlocks 5mo ago

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 5mo ago
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 5mo ago

> 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 5mo ago

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 5mo ago
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 5mo ago
  Interesting. Why not keep on a merge branch before review?

Espressosaurus 5mo ago

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.