I hope we'll be able to do better once we have an open-source storage backend that stores contents in a central database (like we do with Jujutsu at Google).
I don't think anyone has started working on it. We would want a design doc first.
Note that the solution probably involve a local daemon process for caching reads and optimistically accepting writes and then sending them to the server in the background. That's what we do for latency at Google. But that's just an optimization and can come after the server is done.
If you're interested in working on it, it would help if you joined our Discord server.
This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-i.... I'm guessing you didn't click that link. I suppose we need to inline part of the text where we link to it to reduce the number of confused readers.
At this point, I wonder if maybe we should not even mention the staging area. It seems to confuse a lot of people, so maybe it hurts more than it helps to mention it.
Good point, we might want to document that. Btw, I've called it "native backend" and "native forge" myself, but maybe those are not the best terms because there are many possible native backends/forges.
For example, our "Piper" backend at Google is a native backend in the sense that it stores all data in its own database. I think the most exciting thing about that backend is that it's cloud-based so users will be able to access each others' commits (e.g. `jj show <commit id from chat>`) without requiring a push.
I would say that Mercurial has a simpler UX than Git without being less powerful. I think Jujutsu (see other posts here), which I started, also has simpler UX and is more powerful than Git in many ways. Have you looked at either of those?
About a decade ago, I tried both mercurial and git, and at the time had only subversion knowledge. I remember finding mercurial extremely confusing and git very simple, but don't remember the details about why mercurial was confusing.
Whereas conversely I was glad that with Mercurial I no longer had to deal with Git's staging area (for me, Mercurial's interactive commit serves the same purpose).
The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Also, as others have said in sibling replies, refactoring Python is not fun due to lack of static types (I know it's gotten better).
To clarify, jj is not derived from Mercurial, but it's heavily inspired by it. The current DVCS solution at Google (called Fig) is based on Mercurial, however. But we're hoping to replace it by jj.
