3 ms·
It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked
by riwsky 1y ago
It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.
- kadhirvelm 1y agoSounds like your opinion is jj is easier and faster? Would you say that’s true for new developer onboarding too?
- riwsky 1y agoI’ve never onboarded or successfully convinced a colleague to use jj. But roughly once a month I find myself helping someone escape git hell that would either be easier to solve or avoided entirely with jujutsu. I’m not speaking hypothetically: I will solve the problem locally while waiting for them to slog through whatever merge conflicts or stash/unstash dances. But the graphite CLI’s stacked PR review is a killer app. Our team uses it, but treats the rebase-centric workflow as the price of stacked review, instead of a mental model to leverage. I end up using jj but with a helper script to set up graphite’s branch tracking whenever I want to submit a stacked PR. I also was always a git CLI person. I’d do diffs and resolve conflicts in a proper editor, I wasn’t crazy—but I know that changing just my mental model is less work than it’d be to change the UI habits as well.