←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 4 comments | 31 Aug 25 15:31 UTC | HN request time: 0s | source
Show context
jennyholzer ◴[31 Aug 25 16:14 UTC] No.45084302[source]▶
I've seen some posts about Jujutsu recently, but I haven't gone deep into specific workflows.

Are there specific advantages to using Jujutsu over Emacs Magit?

All other Git UIs I've used have been severely lacking, but Magit has made me significantly more productive with Git, and has convinced me of the "magic of git".

Is Jujutsu interested in competing with this experience? Or is it intended as an alternative to the (to be clear, extremely poor) git user experiences outside of Emacs?

replies(7): >>45084369 #>>45084385 #>>45084405 #>>45084556 #>>45084694 #>>45085631 #>>45089962 #
paradox460 ◴[31 Aug 25 16:22 UTC] No.45084369[source]▶
Jujutsu isn't really a git UI, and in some ways it's rather bad at being one (no support for making tags, submodules, or a few other things)

It's a whole new VCS, that just so happens to be backwards compatible with git, and uses git as it's backend

Similar to how git brought us cheap branching over svn, JJ brings cheap rebasing. Conflicts are no longer stop the world operations, and you can rebase, rearrange, and manage commits like never before.

If you've used tools like stacked diffs before, JJ will feel right at home. Making stacked diff PRs is almost trivial in jj

replies(2): >>45084398 #>>45091434 #
1. stavros ◴[01 Sep 25 10:28 UTC] No.45091434[source]▶
I use jj, but I haven't gotten into conflicts much yet. What do you mean by "they aren't stop-the-world operations"? I do like how chill jj is about them (as in, it doesn't interrupt what I'm doing), but I always resolve them immediately. Can I not?
replies(1): >>45093415 #
2. paradox460 ◴[01 Sep 25 15:20 UTC] No.45093415[source]▶
If you're doing a rebase or merge or any other operation, and a conflict comes up, in git you have to resolve it right now, or discard everything. You can't just leave the conflicts in place while you work on something else, they effectively freeze your entire repo. JJ is the opposite. You'll get conflicts, it will tell you about them, but it's up to you to choose when to work on them. You can even keep piling new changes on top of a conflicted one. Your program probably won't work, being full of conflict markers, but you can keep working still
replies(1): >>45094121 #
3. stavros ◴[01 Sep 25 16:29 UTC] No.45094121[source]▶
Ahh nice, I didn't realize it'd carry the conflict markers along. That's great, I really like jj.
replies(1): >>45095377 #
4. paradox460 ◴[01 Sep 25 18:37 UTC] No.45095377{3}[source]▶
You can also resolve the conflict markers in a variety of different styles, not just edit in place.

Say I'm doing a dependency update, and someone else updated different dependencies, and our change sets merge. I want both sets of updated versions, but our lockfiles probably conflict, and I don't want to edit them by hand. I can just leave the conflicted lockfiles till the end of the rebase/merge, then purge them and regenerate them using tooling, and then split them up and apply them down to their respective conflicting changes.

Sure beats having to toss the lockfile, regen it, then let the rebase continue only to find you have to do it AGAIN