←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 3 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 #
jennyholzer ◴[31 Aug 25 16:24 UTC] No.45084385[source]▶
Are there "central concepts" in the Jujutsu design?

I'm having a hard time wrapping my mind around what specific details would cause me to choose Jujutsu over Git, in particular because of Git's industry standard status.

I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant.

I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into.

replies(3): >>45084557 #>>45084575 #>>45084937 #
1. veqq ◴[31 Aug 25 16:42 UTC] No.45084575[source]▶
jj is akin to a wrapper of coherent aliases thrown over git. No one else knows you're using it, because it uses git under the hood. It's just a simpler abstraction without insane naming and flag conventions.
replies(2): >>45084773 #>>45084893 #
2. senekor ◴[31 Aug 25 17:01 UTC] No.45084773[source]▶
I mean, it certainly is that, but not only that. Jujutsu has more to offer than a consistently designed CLI. You can't do non-blocking merge/rebase conflicts with Git aliases. You can't do `jj absorb` with Git aliases. And you can't automatically rebase all descendants of a branch without first merging them all together, which may cause conflicts that then prevent you from performing the actual rebase. Just some examples of "more than a bunch of Git aliases" ;-)
3. baq ◴[31 Aug 25 17:13 UTC] No.45084893[source]▶
it's much more than that. jj decouples the tree snapshot (git commit) from the patch id (jj change id); this allows workflows that are possible in git, but hard or inconvenient; if you add deferring conflict resolution, the most efficient jj workflow is similar but very much not the same as the most efficient git workflow.