Jujutsu is built on top of Git, so it can benefit tools in the same ecosystem (forges, CIs, code quality tools, IDEs, plugins, etc).
I have only played a little with jj and hg, but I felt that jj has a more modern UX, learning from years of Git existence (and even influencing Git, like the new `git history` command [1]). On the other hand, hg was created in the same month as Git, both trying to improve the experience of the VCSs available at the time (april 2005).
Git already won through Github, the Linux kernel, and other important projects. Even if you like Mercurial's syntax better (I do) and wish it won (I do), that battle was over many years ago.
jj's data store is git. You can use jj while other people on your project just use git. There's no migration of data or history. You can use Github and all of the various git tooling that exists today.
As such, the initial cost of switching to jj is zero for individuals, teams, or projects. That's huge.
jj's ergonomics are significantly nicer. Fewer ways to shoot yourself in the foot, much better merge resolution, etc.
It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics.
Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.
You can speak the git protocol over the network only, but one advantage of using the same storage on disk as Git and exposing it in the same way (in a manner that keeps jj/git in sync) is that git-based tools still work. So, people still get diff markers in the gutter of their editor buffers, random scripts that do `git rev-parse` or whatnot still work out of the box, etc. This makes the experience more seamless and imposes less friction on non JJ users, eg you do not have to write a patch and add a special case for JJ because `git rev-parse` failed to run and then ask pretty please to merge it (and then keep doing that forever as you are the only user).
It doesn't sound like much, but before I started contributing to Jujutsu I was a user of https://sapling-scm.com/ -- Sapling is fantastic. It stores data on disk in git format, but back then it was not exposed to the user by default -- the .git directory is hidden away. It actually ended up causing a lot of friction that random `git` commands would not work, or tools had other various git-based behaviors. These days, sapling has a "dotgit" mode (partially inspired by jj I assume) that puts the .git directory in the root dir, so `git` commands still work.
Beyond that though, speaking Git over the network only has other complications on the client side. In particular Git clients and servers negotiate what objects each side has (given what the client requests), and from that negotiation derives a list of needed objects to give the client, and then sends a packfile for it. This is all relatively expensive to do on demand, actually, so it would make the interactivity for network operations much worse if you need to wholly translate your storage into packed objects, etc. And doing it efficiently would require you keeping a cache around that is basically a git database anyway, so you might as well just go ahead and use it. Not the end of the world in terms of downsides, but a trade-off that adds some baggage.
Using a different data store breaks compatibility and dramatically increases the friction to switching to it. jj's superpower is that my usage of it is invisible. Right now I'm working on Github projects in jj where none of the other contributors are. Nothing about my usage of jj requires them to change anything they do.
Mercurial is too slow. Even with chg common commands like `hg status` may take hundreds of milliseconds. JJ is fast. Internally `jj log` taking more than 500ms is tracked as bugs.
Well I did not answer your second part of the question, only the first part of comparing Mercurial vs Git.
Now to the second part: I think speed still plays a role back when Bitbucket and Google Code provides Mercurial hosting and people were comparing Mercurial with Git. Eventually GitHub won the competition, so then we kinda stuck with Git.
Several jj developers (especially Martin and Yuya) are former mercurial developers.
jj borrowed quite a few things from mercurial.
So, jj can be thought at least partially as a spiritual successor. Meta's Sapling is in a similar position. From this perspective, the key feature of both is transparent git repo and git remote support (hg can speak git as a foreign language, but it's limited)
Others have answered about traction. As a one-time Mercurial user, I think the single most significant addition is first-class conflicts, so that dealing with them doesn't stop the world but can be deferred until I'm working on a particular conflicted change. (That also eliminates the need to ‘evolve’.) Easy undo is also nice.
My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)
The oldest known legends that obviously relate to the Arthurian mythology are Welsh.
But the further back you go, the less historical they become. And I don't mean in the sense of historical records being less reliable farther back in time; I mean that the characters in the oldest legends are clearly supernatural figures. There is no reason to postulate supernatural figures as having historical enemies. Why would they?
Yeah. There is a difference between something like Geoffrey's "De gestis Britonum" which was thought by the author to be sort of true, and Malory who knew he was writing literature.
Most of what people think about as part of the Arthur myth are from literary sources, like Lancelot, the Knights of the Round Table, or the Grail quest.
Peredur from the Mabinogion and Chrétien De Troyes Perceval are pretty strongly related, implying that there is a common Celtic source tale, but I don't think anyone has ever found one.
That's wrong. All scholars know he was a Briton, or sometimes called "Romano-Briton". The "English" (Angles, Saxons etc.) were usually the antagonists of the Britons.
I only recently started to understand that the post-Roman "dark age" was not quite as dark as I thought it was. Scholars and other interested parties can tease out a fair amount of knowledge of these times. Even though it gets quite obscure.
I have a recent book by Caleb Howells about "King Arthur" and he goes into some interesting detail about some of this stuff. He also has a YouTube channel. There is real history to be discovered here still (but much can only ever remain speculative unfortunately).
perhaps I am somewhat better informed than others, but I've gone under the assumption that familiarity with the Welsh background of Arthur was the norm since I was in my early teens, so many decades back.
Help encourage alternatives by trying Gitlab.com or Codeberg.org or Tangled.org or others, and please star some projects there to help motivate more options.
Self-promo links below if you would like to star a few of mine good for developers.
Codeberg isn't a viable infrastructure alternative. Its an opinionated community not a neutral host as they will delete repos based off subjective opinions on LLM usage and resource consumption. If continued hosting is dependent on moderators deciding if a project fits whatever the current philosophy is, and the whims of the moderation team, then I cannot consider it a serious choice for infrastructure.
Infrastructure should be neutral. Codeberg is a social club
Can you suggest a viable infrastructure alternative?
My wishlist: free for open source and paid for closed source, able to do simple projects that are handwritten and also complex projects including AI LLM code that needs CI/CD/auditing, and hosting in the UK or EU.
Aside, I donate money to Codeberg because I think Codeberg is a wonderful service with strong commitment to free open source, and because I host some larger projects and AI projects that are for public welfare social good.
https://tangled.org would love to have you :) We're hosted in the EU, and are free for open source, forever. Tangled is also designed to be federated from ground up, so you get to own your infra & data while still participating in an open network.
Tangled is a VC-funded Oy (Finnish limited liability corporation, €3.8M seed a few months ago). I searched and couldn't find a published donation route, which makes sense given it's VC-funded.
To Tangled -- it's great that the core code is MIT licensed and anyone could stand up a competing appview (the credible-exit property of atproto).
Do Tangled Labs Oy's articles include a purpose clause instead of the default profit-only purpose[0]? Or is something similar on the roadmap?
[0] OYL 1:5 reads The purpose of a company is to generate profits for the shareholders, unless otherwise provided in the Articles of Association.
You're deliberately avoiding a network effect lock-in by being federated, you make competition trivial by giving away not only the protocol but also making your code available, and you don't even restrict commercial competition by using the MIT license rather than, say, BSL.
To me that sounds like you are deliberately starting a race-to-the-bottom competition on price with, well, everyone capable of hosting a SaaS? Heck, if you don't end up with some solid competition the whole "federated code" USP doesn't play out. To me that doesn't exactly scream "good return on my €3,8M seed round". Am I missing a brilliant plan here, or should we expect a rug pull a few years down the line?
I feel like any service that is free for open source is going to struggle if it gets significant adoption and becomes a default target for hosting LLM generated code. If even MS/GitHub cannot scale to the current demand, what hope do smaller and less well-funded alternatives have?
Infrastructure can never be neutral, because infrastructure is owned and costs resources to run. All infrastructure comes with rules, be they the voting consensus of some e.V. or state-run entity, the whims of an individual on their private server, or the corporate interests of something owned by a, well, corporation.
The problem isn't "neutral infrastructure". The problem is an overreliance on centralized services even though most such services are relatively easy to host yourself.
I run my own DevOps server based entirely on OSS. Is it github? No. Does it what I need it to do? Absolutely. Do I get 99.999% uptime? No, but when it's down or slow, I can fix it. When the corporate platform is down, I can only wait.
And "network effects" are not a good argument. Open Source was wildly successful long before centraliced DevOps platforms.
And in hindsight, the added friction of getting in touch with projects before being able to send them any code, was a benefit not a disadvantage. Because it acted as a barrier of entry that disincentivized alot of subpar code from hitting these projects in the first place.
The value these centralized services provide is the centralization itself - that makes things easy to find. Remember the web before Altavista? Finding anything was detective work, guessing domains, following links through multiple pages, digging in newsgroups, asking around, and so on.
Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
Now, if we could do something like GitHub on top of a network such as Mastodon, then we would have something that's centralized enough to be useful and distributed enough to be indestructible.
> Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
None of that depends on a centralized provider. I have all the features you listed on my self-hosted platform as well.
Codeberg is one public flagship instance. They are not neutral and don't claim to be. Decisions on what to host are made via elections by e.V. members. Other platforms (GitHub, GitLab, Tangled etc.) will eventually run into this same thing as well, e.g. how GitHub responds to DMCA requests, the difference with Codeberg is that there are elections which decide on what gets hosted on the main instance. For hosting slop or running a ton of actions, the recommendation is to self-host Forgejo directly instead, meaning that you, not the e.V. pays for the consequences, and you'd use the future AP federation support for cross-instance support. Forgejo is particularly simple to self-host as well, and lots of people do it (ffmpeg, Fedora and more). That way, you get to set your own rules and e.V. election results have no effect on you.
I'm often surprised to find very questionable repos hosted on GitHub. Such as plug 'n play malware that has been public for years. Not against it, but surprised as most parts of the internet has gone in the kindergarten direction.
Infra should be immutable piece that is certainly not influenced by someone power tripping or being butt-hurt by conflicting alignment on worldview issues. These things should be completely detached from each other, and infra should be neutral with technical guarantees it cannot be cut off aside of warfare acts.
This gives the impression that there's a collective group of differing views that come together and make decisions. It's quite the opposite from my experience and they seem to actively chase out anyone who dissents from the collective hive mind's view.
while I don't know if your allegations are true, democracy means there is a group which decides on rules based on a majority vote. It doesn't mean that they have the same or different views at all, although some overlap is probably certain, because otherwise you probably wouldn't decide to join the same association.
Anyone who joins the association (small fee) can vote.
I know what the technical definition of democracy is. However, a lot of people throw it around as if it insinuates a free and open system where every idea can be voiced. That's certainly not the case at Codeberg, and they make that fairly clear. They heavily moderate content and view points that challenge the hive mind are generally moderated out of existence (or the topic/thread is simply closed).
So, yes, it's technically a democracy, but it deserves extra nuance in my mind because it might not be what everyone immediately thinks a democracy should feel like.
That's a fairly good starting place. Might seem innocuous, but don't forget that "far right" has no agreed upon boundary. You might as well replace it with "wrong think" at this point.
Which, again, good for them. I could care less. I left a little over a month ago once I figured out what was going on. They are perfectly allowed their fiefdom on the internet, but I would never recommend the platform to anyone as a useful Git forge unless they happen to sit in that little thought bubble.
Judging by your response, you wouldn't be persuaded by anything. But, I suppose to provide an opportunity for education, people do not like to be thrown into an ever growing identity group with an ever growing list of negative associations tied to it. It's not shocking to me that the people running Codeberg are oblivious to the hypocrisy and double standard they seem to be blatantly putting out. It doesn't foster "inclusivity" and tends to drive out reasonable people.
But that's the game, I suppose. Everyone knows what's going on and they just don't care. And so I don't care about Codeberg :)
Rather use BitBucket or GitLab really, both GitLab and BitBucket have been around nearly as long as GitHub? Apparently BitBucket and GitHub are both 2008, and GitLab is 2011. The others you mentioned could go on a whim.
I started my career in programming with Subversion was the most popular tool. I also had to work a little with VSS, Perforce, Mercurial and, obviously, Git. I was one of the first users of Google Code...
So, relatively, not so long ago it was pretty common to host all this stuff yourself. I don't think (or maybe don't remember) Subversion having any Web interface of its own, but, since forever Git came with GitWeb. I remember configuring it for the first time: any extra bit of configuration, especially those that resulted in some added interactive functionality seemed exciting. For a week, I'd push something to my branch and immediately refresh the browser page to see my changes reflected in the remote repository :D
The infatuation wore off very quickly: after a month I have almost forgotten the Web interface even existed.
The cycle repeated with hosted services, the addition of PR interface, the addition of "pages", the bug reports, the built-in Wiki. After discovering the new gadget and associated hype, invariably, came the realization that the predating existing functionality was... better. The PR discussion in the Web page detached from the code is a lot worse than the PR discussion in the PR itself. The built-in issue tracker doesn't come close to the stand-alone product functionality. The built-in Wiki is ridiculously underwhelming when compared to an actual Wiki.
And so was the CI. For me, it started with Gitlab. There are oh so many reasons to hate Jenkins, so, whenever anyone announced an alternative platform, I'd absolutely check it out, and so did a lot of others, I presume. I was super hyped up about the possibility of running CI from the command line, completely locally on my laptop. And then it turned out to be a bait-and-switch kind of thing. I've created monumental dozen-steps and branching pipelines connecting multiple projects only to realize that the best CI is the one that uses as little as possible of the platform tools.
In the end of the day, I came to realization, that beside the social aspect of the platform like GitHub, everything that it offers on top of the essential Git repository storage is too low quality. And so do competitors. If I was ever again tasked with setting up a company code repository storage, I'd go with a physical server attached to the local office network, unless there's no office, in which case, probably, some EC2 VM would do the job...
Places like GitHub or Gitlab lure you in with their free tier offering, where you get the storage space and some other goodies for free, but once you need to upgrade to the paid tier, you inevitably realize that it's not worth the money they charge for it.
GitHub being ruined after the AI hype is a shallow take imo.
The root problem isn't AI, Microsoft, or Azure; It's why people keep _trusting_ centralized infra.
GitLab and Codeberg can absolutely become trash, each in their own way.
The solution isn't just "migrating off of GitHub"; it's "migrating to a platform that is unownable by design, not only hope".
And there are no good enough decentralized alternatives to GitHub yet.
Tangled.org's decentralization has serious holes.
Radicle made an alien universe; a niche within a niche. Also, it's already having problems with ISPs:
https://radicle.dev/2026/04/23/domain-move
Azure was arguably as garbage four years ago as it is today, the only thing that's changed in the past few years is MS mandated vibe coding, and suddenly Github has an outage every week? A ridiculous coincidence if it's not causal.
The main hole is that ATProto's data model is a bit awkward for a code forge.
Issues/PRs/comments are records owned by their authors, not by the repo. So an issue can span N users' PDSes. That's a neat model for social media, but a forge wants the repo to be the durable owner/context of its issues and history because that's where the comment/issue/etc. logically belongs.
The solution? tangled.org acts as a super advanced cache/aggregator for that. What can possibly go wrong?
There's a good chance this will change in the future and the repo on the knot will also contain the social aspects of repos (issues, PRs, etc.)
> As time goes on we are re-assessing the idea of users owning what is "collaborative data" (issues, PRs, etc.) on their PDSes - soon may come the day that an issue also lives on the knot as a source of truth, with an accompanying pointer record on user PDS to attest that it's theirs.
Worldwide medical standards implementations with Rust for FHIR, openEHR, SNOMED, etc. Official specifications work well with Claude Fable, test automation, and storage using relational databases.
Fast Healthcare Interoperability Resources (FHIR) using Rust:
Do any of those specs address de-identification or pseudonymisation, or is that always left to the implementer? I've hit exactly that gap with an app I am working on so would appreciate to hear what you have to say on the matter.
Yes in some senses, but no from a compliance perspective. This is AFAIK and IANAL and YMMV etc.
For example: The standard FHIR $export operation can support extensions that take de-identification config details as additional parameters. The standard openEHR can query then return non-id fields. The standard SNOMED codes can be rolled up e.g. high-specificity codes can be aggregated into a low-specificity code.
But: for compliance/legal/auditing reasons, all organizations that I know of personally do not rely exclusively on these protocols for de-identification. Instead, the organizations place their de-indentification processes in a kind of "clean room" that does many more kinds of cleansing, redacting, aggregating, chaffing, filtering, and the like.
I'm experimenting with large-ish software projects using Claude Fable. The results are surprising to me.
- Project portfolio management software. Good results so far. This is unguided experimentation: Fable researches feature ideas and plans them, then Opus 5 implements them, without me in the loop. The features include things such as an auth server, full-text search, audit logging, resource leveling, HA/DR, IaC, and more.
- FHIR & SNOMED medical software experimentation in demo-only environments. This has mixed results so far. This is guided experimentation: the FHIR specifications and SNOMED specifications are thorough and I'm in the loop. Fable plans OK, but Opus 5 is thrashing a lot, going down many rabbit holes.
Lots of errors. Opus 5 is also giving me many more hallucinations, including things that aren't even in the right territory. It's also telling me that it's making many mistakes, and the language feels off-kilter as if it's not using typical clear phrases.
Yes, it’s way off field in many things, gets into weird minutia without seeing a way out, and it’s often seeing a clear sequence of work but then halts on a statement like “ok I’m going to start now.” Then after expiring the cache when I notice and ask why didn’t it the response is “no reason starting now!”
I see this behavior constantly in 5 - the quality of opus and fable have degraded constantly since 4.6 was such a riotous success
It is aggressively proactive in ways that make it very hard to use. I had to turn down the effort level to “low” to stop it from going off in random directions every couple of turns.
I saw this even on the weekend when it wasn't under heavy load. We agreed a problem was due to one choice of word in a prompt and then it went off and wrote 600 lines of code to "fix" the issue.
Opus 5 / Fable - instead of implementing things one-by-one in a branch - decided to branch off and do everything from the starting point - meaning that they re-did work over and over, in different ways, and that almost nothing could merge back at the end.
Looking through the logs, it kept saying, "Wait I'm confused. I already did this." But I guess it decided, oh well, I'll just do it again instead of take a second to figure out what I'm doing...
Yeah I noticed informing me of mistakes it made during sessions. It felt really off when it informed me of a mistake it almost made but caught it before it landed.
Our model is that data is encrypted in the application before being saved to the database. In order to encrypt, decrypt or query, you need to use the SDK (@cipherstash/stack). Connecting via psql, pgadmin etc, you'll only ever be able to see encrypted values (those tools don't know how to decrypt).
Proxy connects to the database and then you connect to the proxy (with psql or whatever). Proxy can now perform queries and decryptions on your behalf so that you can still access data if you need - hence "escape hatch".
The proxy authenticates using your credentials (or an access key) and interacts with the key management server.
If you haven't tried jj yet, take it for a spin and see how you like it.
reply