Live data from Hacker News

Jujutsu for busy devs

maddie.wtf

21–30 of 552 posts

Re: Jujutsu for busy devs

#21
post #15

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it.

Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.

Re: Jujutsu for busy devs

#22
post #11

Earlier quoted context omitted.

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in j…

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial merge conflicts which is going to be an issue no matter you use.

Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the ass do you think it would be if a later change conflicted with this earlier change?

It is essentially zero work in jj. I `jj edit` the revision in question, make the change, and `jj push`.

Re: Jujutsu for busy devs

#23
post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it. Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.

Note that jj is not a frontend for git or an abstraction layer over git — rather, the git object store format is one of at least two backends to jj.

Re: Jujutsu for busy devs

#24
I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49.

Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500?

EDIT: I am looking for tutorials with explanation on how JJ works, preferably without referring to Git, and even more preferably with some visual explanations, which, there are plenty for Git. It seems I am not very good in reading text trees. It is my issue, not yours, but may be you know something which would help.

Re: Jujutsu for busy devs

#25

Earlier quoted context omitted.

Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it. Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.

Note that jj is not a frontend for git or an abstraction layer over git — rather, the git object store format is one of at least two backends to jj.

Thanks. That would make me interested in it for a personal project where I only use jj.

Re: Jujutsu for busy devs

#26
post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.

This has been the case, but it's worth noting that very recently, support for theming with the 256-color palette has landed too https://github.com/jj-vcs/jj/pull/6763

Re: Jujutsu for busy devs

#27
post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.

Some programs set the background colour and some don't. For example pamix sets the background to black, or tmux's statusline, or ngrok. It's not really possible to define one terminal scheme that always works.

Re: Jujutsu for busy devs

#28
post #24

I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials wi…

Try https://senekor.github.io/jj-for-everyone/introduction.html .

A snippet from the intro:

"At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This blog post is my attempt to fill the void of beginner learning material for Jujutsu."

Re: Jujutsu for busy devs

#29
post #24

I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials wi…

> Is there a good explanation of Jujutsu without referring to git?

There can and will be, but at this stage in the project's life, git familiarity can be assumed.

> Am I the only one bad with memorizing SHAs when reading?

Nope! The CLI has nice syntax highlighting to show you the shortest valid prefix, so for example, right now I have something that looks like

  lzrvnkxl
but the initial l is in purple, while the zrvnkxl is in grey. This means I can just use the l when referring to the change. That can be harder to demonstrate in a blog post, which can't know how to highlight this, and so often they have no highlighting.

> Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500?

Yes. Because it's backed by a git repo, nobody else needs to know you're using jj. Everyone can use the tool they choose.

Re: Jujutsu for busy devs

#30
post #24

I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials wi…

Git is nearly universal, so highlighting the areas where jj makes things that are painful in git trivial and obvious isn't exactly a bad strategy. It's also worthwhile pointing out that it is interoperable with git, so your company and team don't have to change just because you do.

> Am I the only one bad with memorizing SHAs when reading?

I haven't ever needed to memorize a SHA or change ID with jj. What are you referring to?

> Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500?

I have used jj for two years on teams without anyone else needing to be aware. Other teammates that I've convinced to give it a shot have switched, and we all work together happily alongside the git users. If anything, it's easier to work with others when they switch to jj because you no longer have to worry about rewriting history of branches that have been pushed. If you have a branch that multiple people are working on, that's bad form in git but it's just another day with jujutsu.

Post reply on HN