What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.
There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all.
So yeah this is still basically a recommendation for people to try JJ!
I think all of those are using git and many Gerrit as well.
If your project is open source but still interacts with the main body of Google code in a significant way, you can still be in the monorepo and then mirror it to Git via Copybara (or you can work primarily in Git and then mirror to the monorepo via Copybara).
The most common case of that is libraries that get imported into server binaries. There's a whole section of the monorepo for open source code, with special rules and processes around it.
But a that has setup and friction costs so it's only worth it if you see a pretty significant upside.
For stuff that's pretty standalone there's no point. Classic cases are Chromium and Go. Then of course there's Google's various operating systems...
Is this one of the repos that uses Gerrit? Does JJ play well with Gerrit?
IIRC Gerrit was super picky about amending commits and I was worried JJ's laissez faire attitude about creating git commits on demand wouldn't jive well.
There was a PR for a `jj gerrit` command, but at this point, it's not super needed. Here's the main bug tracking this https://github.com/jj-vcs/jj/issues/4387
Beyond that, the jj, gerrit, and git butler folks are working together on standardizing the change ID concept so they all work well together without extra tooling. That's going to take a long time though. Think "store the change ID in the commit rather than as a trailer", that kind of thing.
JJ does create commits without you explicitly asking but you do still have direct and fine grained control over it. It's not magic it's just that it's occasionally implicit. And squashing and splitting is nice and easy.
It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me. Even though my main work involves quite a lot of annoying rebases which is where JJ really seems to shine.
I dunno I guess it's just that a) I've really mastered git and have a deeply-rooted workflow in it and b) despite my project involving annoying rebases, version control still isn't very high on the list of problems I have.
So yeah I'm basically bullish on JJ as a technology but I think movement from Git is inevitably gonna be slow and steady.