by Curiositry on 5/26/25, 2:16 AM with 56 comments
by mtndew4brkfst on 5/26/25, 1:37 PM
https://matklad.github.io/2024/12/13/majjit-lsp.html
With that yearning in mind, jjui is the jj TUI I like best so far having tried them all. It's snappy, has useful and intuitive keybinds and presents them well, and good stability so far. Doesn't quite seem to like it if I resize the surrounding zellij/terminal pane while it's open though.
Lazyjj was a little laggy and crash-prone for me on all of the same repos, and jj-fzf is a tragic pile of bash so I can't recommend ever using that.
by cube2222 on 5/26/25, 9:57 AM
I've written about JJ[0] when I was starting to use it, and now, a couple months in, it's become an indispensable part of my workflow. Git really does feel clunky now (even though I never had major problems back when using it), whenever I see it used - with jj being compatible with it, fortunately I don't have to ever use it myself anymore.
Historically I never cared much about my git history (and always squashed PRs) - now I find myself occasionally using empty changes with good descriptions to just write out a sort of todo-list on my branch (kinda CDD, as in Change-Driven Development :) ), and it's overall much cleaner.
I've always used a ton of stashes with git for various experiments and in-progress work, now that's just normal local-only jj changes. Also solves the very unpleasant problem of rebasing stashes.
If you're reading this comment section thinking about whether it's worth trying jj out, I would strongly suggest you give it a go!
[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
by endtime on 5/26/25, 7:46 AM
I started using jj a few months ago. I had used Fig previously when I was at Google, but then spent over 2.5 years just using git, and using jj was like riding a bike. It's more or less exactly what I want it to be and I use it as much as I can.
That said, here are some of my pain points (despite all of which I do still prefer jj to git):
* No GitHub PR sync for stacks. Managing stacked diffs locally is great, but (a better version of) Sapling's PR syncing would be a huge value add. This is somewhat of a pain point for me directly, but even more so a weakness when I've tried to evangelize jj internally as a viable "stacked diff" solution (e.g. to be blessed by our eng tools team). Someone familiar and comfortable with Sapling (or just skeptical of jj) can easily point to this feature gap in a way that pretty much ends the conversation.
* I wish the native backend supported pushing/pulling changes. I want to be able to switch between working from my laptop and my workstation, and doing that through pushing to and pulling from GitHub is obviously lossy of jj history. Manually copying the .jj directory seems to work if I'm careful and do everything correctly (i.e. make sure both clones have equivalent working copy state when I copy .jj), but this feels brittle and it's easy to mess up.
* If you forget to start a new rev before you (or your LLM) touch the repo, it's a little bit of a pain to go back and split the changes into a new rev.
* Some of the more mature repos I've worked with have tooling/scripts/tests/etc. that seem to look for or rely on the presence of .git (perhaps indirectly). Perhaps I could have gotten around this with colocated repos (i.e. `git clone` and then `jj git init --colocate`), but in at least one case I just gave up on using jj for a given repo and just made a separate git clone. I'm not sure this is really jj's fault so much as a practical compatibility gap with git (again, possibly entirely solved by using `--colocate`).
by sam_goody on 5/26/25, 10:11 AM
With so much VC money chasing so many established niches (eg bun -> node), and so much potential growth for jj - especially considering it has so much dev interest, and has the advantage of not requiring lock-in [a jj repo can be converted to a regular git repo].
by dcre on 5/26/25, 1:58 PM
That said, I switched to jj after using GitUp https://gitup.co/ for many years, and I was pretty surprised not to really miss it when using the jj CLI. The things I liked most about GitUp are all covered by the jj CLI pretty well:
- Undo
- Interactive staging (well, in jj the analogue is interactive split with jj split -i)
- Feeling like you’re manipulating the DAG directly, picking this up and plopping it down over here (jj rebase)
Notably, jj already builds in a TUI for the spots where interactivity is most beneficial.
by skeptrune on 5/26/25, 7:22 AM
by account-5 on 5/26/25, 11:12 AM
by silvanocerza on 5/26/25, 7:44 AM
I've been testing out Jujutsu this weekend and this will come in handy. I still need to wrap my head around the different overflow and this might make it easier.