I see a future in jj (steveklabnik.com)

I guess I see what the author was trying to convey talking about Rust/Go at the start but I'll admit it confused the hell out of me when we got to Jj (horrible name IMHO but whatever).

Jj is a VCS, it was not at all clear (to me) until I got further and I was very confused as to why we were talking so much about source control (I thought Jj was a language since the article started by talking about Rust/Go).

Apparently Jj can work on/with git repos making it easier to adopt incrementally which is neat and the main point of this post is that the author is leaving Oxide to go work for a new company trying to to create the GitHub of Jj (my understanding at least).

I hope this helps someone else who might be confused like I was.

Since JJ has technically git compat, I think there's 2 things needed for it to take off

1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs

At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted.

I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.

Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.

Off-topic: I found it very surprising the Logical Awesome website still works.

Congratulations on the new adventure, Steve, and good luck!

jj describe -m "Good luck, Steve!"

Congrats on the new role, sounds exciting - looking forward to seeing where it goes!

I’m just sad pijul doesn’t get the same attention or love from the community. It desperately needs an ability to colocate with git.

[flagged]

I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the same time). So something like what this author is working on is needed.

After reading the article, the technical merits of `jj` are completely unclear.

I think the real news is that some people have started to build what might become something like a "jjhub".

https://ersc.io/

I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review?

I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.

But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.

> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size.

I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing, all in 7-ish years?

One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.

Steve, Rain, please call it dojo.dev or something before jjhub catches on.

So excited for this. I talked to the ERSC folks last year about joining but it was a little early for me. Still incredibly excited about what they're building and glad to see one of my favorite people joining the effort.

Steve, if you come to NYC hit me up!

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

What I miss from the Perforce and Subversion days is committing directly to trunk in a team environment. Now everything revolves around PRs and lengthy code review. With direct commits to trunk, everyone was in a rush to get their commit in before someone else did, so they didn’t have to update and have conflicts. This made commits small, frequent, and usually well-scoped. What -sucked- was when you did need to do a large refactoring or other big change, then that was work best done on a weekend because branching and merging didn’t work very well.

Git’s model is right for PRs for open source projects where one day you could wind up with code from someone you don’t know and you need to take your time in review and possibly making further changes before merging. But as much as git’s a meaningful upgrade over Perforce and (especially) Subversion, branching and merging is not the right default model for normal team development.

Is there a jj tutorial not assuming git knowledge at all? I'd love to see how to approach jj without git.

Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.

This is one person's career move that is defended by the idea that they somehow always make good bets. This is more than a bit arrogant. Past performance is no guarantee of future results.

I don't see a future for this. I see a series of blog posts that culminate in a tone deaf "What went wrong" finale.

For all its warts and less than stellar UX Git is good enough (from a former Mercurial user)