I absolutely love jj (just check my HN comment history). One thing I'd love to see in jj though that git does better is copy tracking. If somebody renames a file upstream, and you go to rebase your commit that touches that file onto main, jj doesn't handle this very well compared to git.

Do you have any idea if this is coming to jj soon?

Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.

excited for what you guys would be coming up with ;)

btw, did Martin leave google?

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site.

While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not possible. And that's the core tech we have built.

With the rise of agents, more and more companies are running into the limits of what Git can do. It was never designed for large monorepos, and so there are performance issues, but also features that it's missing, that are important once you start trying to scale things up to an entire organization. Companies like Meta and Google ran into these things well before the present moment, but you don't have to be a FAANG these days to be running into this sort of stuff.

We also understand that incremental adoption is really important, especially for something as fundamental as source control. So our tech also has a git ingress/egress that will work with the core functionality, but more advanced things that git simply can't do will end up requiring using a non-git protocol. jj is the bridge between those two worlds.

I hope that makes sense! We have been in psudeo-stealth for a while now, this is the start of us coming out of our shell a bit and actually talking about what we're doing.

> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).

FWIW I think it's a bit more nuanced than that. As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. The way this works is that we basically store the sides of the conflicting trees in the Git object database (and another conflicted tree pointing to all of them), but the actual data structure representing the conflict as Jujutsu understands it is stored elsewhere. Git will be very confused looking at a conflicted tree object created by Jujutsu -- it shouldn't break but it doesn't understand what it's seeing. So, if a object can be stored in the database that is correct but Git can't really "view" it properly, does "git" (or capital-G Git) support it or not? Depends on who you ask, I guess. The storage layout being intimately tied to Git "as a thing", part of its identity, is one of the most interesting properties it has.

The way I see it is this. Jujutsu uses the Git storage layout on disk. But basically all of the algorithms and UX between the two are completely different. That is where most of the real differences are. To the extent we integrate with lots of fiddly Git details (eg tracking branches, remote integration etc) so that `git` commands work -- that's more necessity to make the UX nice. We could absolutely use the on disk Git format but in a way that was inscrutible to the `git` CLI, it just obviously would not be very nice.

As a disclosure I work at ERSC but I am also one of the maintainers of Jujutsu; this post is written with my maintainer hat on.

[1] At Git Merge last year, Elijah Newren prototyped and demo'd a really early and cool example of storing first class conflicts in Git, based on his work on ort-merge. So this might not be true forever :)

"Can do" and "can do easily" or "can do with minimal friction" aren't the same.

I use JJ locally and for those that call it a "porcelain" or a "git UI" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural and you can really see this when you start using a JJ driven repository with Git tools (including just the Git command line tools).

Personally, and as a mere version control user, I prefer the JJ model of version control much more than Git's. The mechanics of the UI was very easy to get under my fingers (the essentials in about a day), but getting the ideas and really getting an understanding/appreciation for the conceptual differences and their ramifications on workflow took a month or two of regular working and trying things. For me, it was worth the effort.

I might be mistaken, but I always figured the end goal for jujitsu was to use its own backend. Supporting git-colocation seems like a compatibility case to bring users over.

If I had to guess, then I would say ERSC is trying to build a `jj` forge based on this new hire and that would be amazing imo.

> jujutsu works with git.

Just like TypeScript with JS, QUIC with UDP, GraphQL with HTTP, Android with Linux, and so on

> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git)

Replace "jujutsu"/"git" by "typescript"/"js", "quic/udp", etc and you'll understand.

If you ask "apart from better UX, what's the advantage of this thing?", you might as well ask "why would I buy an iPhone when my Nokia can do more things?".

Assembly can do everything Python/Java/Rust can do yet you might not wanna code in assembly if you don’t have to.

this is a very legit question. my few cents:

I don't know how experienced you are with jj, but one thing I can say for sure is jj offers significant ux improvements over git and they plan to have a backend eventually. we might see the first implementation from ersc. and from their website I see they are already taking things like agents into account from day one. so we might be in the verge of getting something that scales better with modern day workload?

Absolutely everything in this industry is just a façade over the underlying ability to pass current between the source and the drain of transistors. "Just a better way to do ______" is the entire software sector.

How is this undo different than Git's reflog? Genuinely curious, while I have heard of jj I haven't yet tried it (I read it couldn't handle git submodules, which would have made it dead in the water for my dayjob, that seems to still be the case).

A term coined within Google that describes the best part (to me at least) of jj: delayed conflict resolution.

You worked on multiple things, you sync with the upstream, then boom now you have conflicts in one or more of your local branches.

Instead of immediately presenting you a conflict resolution view (usually 3 pane vimdiff) and you'll have to resolve at the sync time, the commits are simply marked as "have conflict", and you can continue working on other things until you have time to deal with it.

And for a chain of commits that all have conflicts, chances are fixing the first conflict automatically resolves all other conflicts in the chain, thanks to the auto-rebasing feature.

Are you saying push + undo = unpush?

How does it compare to Mercurial? And why would it get more traction than Mercurial?

Yes, he joined a few months ago, this is just getting it onto the site :)

I think it's closer to: develop something similar to Google's Piper as (hopefully!) an open source project and sell this to enterprise, similar to Perforce's business model but with the benefit of an excellent and well received frontend tool.

It's in the post, but Martin will be continuing to work on jj itself as well as on our products, just as he did at Google, working on the open source jj but also their internal source control team.

As a side note, jj has rules around company representation in maintainership, and so when this initially happened a few months back, ERSC actually became over-represented in the maintainers group, as we also employ several other maintainers. The project decided to add more maintainers to keep the balance, rather than ask folks to step down.

We very much want to properly support the upstream project, and we want to make sure that it continues to be awesome for everyone, not just our customers.

We (East River Source Control) don't run Jujutsu, it does not "belong" to us -- it is a community project! Nothing has or is changed. Most of the contributors have nothing to do with us/Google/whoever. We get tons of great contributions from highly experienced and talented individuals. It's healthy, check it out: https://github.com/jj-vcs/jj/commits/main/

Most of the maintainer stuff is also overhyped in a way (OSS maintainer-heads know this). The maintainer group is largely structured to just keep things moving; not really a privilege but a responsibility -- making sure things get merged, doing technical reviews, ensure builds are unstuck, and hitting the green approval button. Our own community members also do code review, find bugs, triage things, answer questions, design features, help get users unstuck, etc. We are very much not alone, and I have great confidence in the constitution and strength of the community itself as someone who has been around the block a few times.

This is going to sound silly and "guy approves of himself" adjacent, but I've been doing OSS maintainer stuff for like 2 decades at this point, and jj is truly a gem as a project. It is vibrant, and the community is generally speaking insanely talented (huge number of git powerusers), and we have a weird dogfood advantage where people use the tool to contribute right back to it. Martin did an awesome job setting the tone of the project just through his behavior before many of us joined years ago. He's a naturally good project lead.

As I said elsewhere: I work for ERSC and I am a Jujutsu maintainer. This is just me speaking candidly on my own behalf.

The article says this:

> von Zweigbergk will continue to be a core maintainer of JJ as an open source project under the Apache 2.0 license.

Isn't ERSC aiming to be for jj what GitHub was for git? In which case, this would be great news for jj.

tell that to Doug Englebart or J.C.R. Licklider-- the idea of human-computer symbiosis predates basically all computers that we would recognize as such today. crazy how it is only really now becoming true in the way that they envisaged in the 1960s.

I joined ERSC ten months ago!

The things I am most interested in right now are jj and llms. And the intersection between the two. I'm thinking a lot these days about how agentic development is changing our industry, with source control being one part of that.

We tested it in mobile, but several people pointed out that we have more performance work to do to make sure that the animation is fast on lower-end hardware. I don't know what phone you're using, but we'll get it fixed regardless.

Thank you!

We liked our old look, but one funny thing about how things are going in the world: our old color scheme was too close to what happens when you ask Claude to generate a site, and so even though we paid a human to build it, we didn't want to communicate slop, especially because that's not what we did!

Nick Noble is our designer, he put in a bunch of work on this, and I really like it too.

Thanks!

There will be a lot more of it soon :D

It's killing my GPU tho so can't look at it took long without my fans going to max.

Filed a bug, looking into it!

Edit: a fix is in review

We have a colopholon! https://ersc.io/colophon

Rust is the default language for all of our non-frontend web stuff, yes.

Fixing, thank you!

(Martin joined back then, but we are posting about it today, so we should have the post date as today)

I wrote a bit about this here: https://news.ycombinator.com/item?id=49526190

I wrote about why I joined the company back when I did previously here: https://steveklabnik.com/writing/i-see-a-future-in-jj/

In short: we are building a next generation source control system for the enterprise.

Thanks, I was trying to work it out in my head. I knew brazilian jiu jitsu was 20th century, and I was like "but wait, is jiu jitsu itself not that much older, that seems very surprising."

Not off topic!

We should be respecting https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A... . If we do not, that's a bug, and please let me know what browser/OS/whatever else combo you have if that is an issue.