This. It's not like we are looking for something slightly better than git in some opinionated way. There's plenty better than git. Mercurial is better than git and as old as git. Git won. Everybody uses git. Everyone who knows, how to use git, is mostly comfortable using git. At this stage we either need something ground-breaking (and I don't quite imagine what this cold be in the context of VCS - even truly semantic conflict resolution barely cuts it, while simultaneously being pure unattainable magic), or I don't think this is gonna float. I don't need it. Who needs it?
It's a relatively easy thing to adopt something you don't need, when you are the only person involved. But VCS is pretty much in the same category as instant messaging and social network platforms are. In a sense, maybe it is a social network platform. I don't see it happening and I highly doubt I would want it to happed, even if I knew this jj stuff better.
Git won because GitHub turned the whole contribution model into a resume-making social media game. The first generation on GitHub pressured the second one into using it at a time when the DVCS scene was still nascent (and git's many flaws, more excusable), and the second one, now turned into a critical mass, made it acceptable for the next to just cargo cult a few commands instead of learning their VCS, because that was the bare minimum to _partake in the game_, and an acceptable trade-off to deal with a now objectively user-hostile and inferior tool.
The nice (and quite unique) thing about jj is that it takes all the good cues from systems which kept improving (and in particular, from mercurial), and slaps them onto git without requiring a storage model change, practically offering the social "perks" of GitHub (by being fully compatible with it), with no-compromise. And to be honest, at this point, there isn't much reason for a new comer to learn git rather than jj, and that's a wonderful news in my book.
> isn't much reason for a new comer to learn git rather than jj
The reason would be that jj uses git as a backend, and all your coworkers use git, and the whole world uses git, so using jj while not knowing git is like being "html-programmer" that doesn't know what RAM is. Surely one can live like that, but I wouldn't want to work with him.
On other hand, what is the reason to learn jj rather than git? What actual problem it solves?
"the whole world uses git" is a weak appeal to the masses (Argumentum ad populum), i.e. the popularity of git is no measure for its qualities, and we should collectively strive for better (just looking around should make it painfully obvious that there are many good things that git is lacking).
We previously saw that git is in fact two very distinct things: a repo format and a user interface; and we saw that git is too critical a mass to be dislodged as a repository format.
The next best thing we can do is then to address its disastrous UX, and this is precisely what jj is about. And it tackles that without even incurring "contagious" changes in established organizations: neither you or I have to know/care whether others are using git-cli/vscode gui/jj/whatever.
This is progress, because teaching git to this day is in equal parts teaching "DVCS theory", git "the useful parts", git "the very many pointy bits not to get too close to", and git "I messed it up, please help me rescue my files".
At least jj offers to simplify the learning while improving on the experience greatly, by offering a very cohesive, straightforward, discoverable safe and mostly trouble-free implementation whose tenets that can be intuited from the theory.
Jujutsu has Git as a supported backend, so it does not need network effects to succeed. I was using it full time at Oxide for many months before anyone else was aware of it.
More generally: I am more knowledgeable about version control than 99% of people (having worked on it full time for many years). The Git UI is well beyond papercut bad. Many advanced users use the rebase-interactive workflow, which is broken in numerous ways.
See my testimonial (top one on the page) for an example where Jujutsu's rethink of VCS basics leads to an incredibly coherent interface. Jujutsu is built by world-class developers who have spent many years working on other systems and drawing lessons from them, and it shows! https://martinvonz.github.io/jj/latest/testimonials/
If I were introducing version control to someone new, I would not be proud of introducing Git and would constantly apologize for it. I'd be proud of introducing Jujutsu.
Why do we invent new programming languages? We can achieve everything with just C or assembly.
As an example of something that's much easier in Jujutsu and very difficult with Git is to work on all branches at the same time. With Jujutsu you can rebase all branches simultaneously too.
See my testimonial in the other reply to yours. Jujutsu is both more approachable to newcomers and does a fantastic job catering to some of the most advanced workflows. It is truly special (this is not something I'd say for almost any other software project).
I've read it, but it doesn't quite answer my question. What I'm hearing is basically "well, it's nicer". Sure, I can believe that even not delving into the subject, because pretty much everything is nicer than git. A bunch of aliases and 3rd party diff are nicer than default git too, I don't think this is what we are talking about. But what problem it solves?
You are saying that rebase-interactive workflow is broken. I do rebase-interactive a lot. Well, maybe it is broken, maybe I would get annoyed about it beyond belief if I spent as much time messing with its internals as you (supposedly) did. But I don't think I often have problems with it as a user. I guess conflict-handling could have been much smarter, but if I keep "temporary" commits very small and atomic it somehow manages to do the job better than I sometimes expect, and in the end I don't think I have any problems with it whatsoever. So, once again, what is the problem jj solves? Can you give some practical, not overly-contrived example when using jj over git is not "nice", but significantly useful, when it saves me somehow?
Let's say you have a stack of three commits, A <- B <- C. Let's say you do a git rebase -i with edit commands on A and B. You make some changes to A, then you go and edit B.
But then you realize that some changes you wanted to make to B, you want to make to A instead -- you want to go back to A.
git rebase -i doesn't let you go back to A. (In other words, the modal nature of git rebase -i means that you can't do a rebase -i inside of a rebase -i.) Instead, you must complete the rebase -i and go to C, and start a new rebase -i.
Now that doesn't sound like a problem, but let's say C is not just 1 commit, it's 10 or even 20. And maybe there are branches with experimental work that you're grabbing bits and pieces of.
And those commits have significant merge conflicts that you must resolve immediately before you can go back to A.
In contrast, Jujutsu isn't modal. You can freely move up and down a stack, and merge conflict resolution can be deferred until later.
(This isn't a contrived example. I literally just finished up a few weeks' work on a stack of 14 rather substantial commits. At its peak, 12 commits were outstanding, totaling around 15k lines of code. Jujutsu handled this extremely well.)
edit: apologies, monospace formatting isn't working well on HN. But I hope you get the gist.
One simple example is undo. You can simply run `jj undo` if you made a mistake (it obviously won't unpush commits to a remote and such). You can go back as many steps as you like.
For me, this framing is backwards: git cannot achieve what I can with jj. jj has everything I love about git, is more powerful, and is more orthogonal (read: simpler).
I have been using Git for 8 years and haven't had any bad experiences with CLI. And this one and other tools that are supposed to replace Git are better in what way? The only thing that's better in this is the conflict resolution but other than that, it doesn't offer that much.
I've used Git for over 16 years and have countless of papercuts with the CLI. Of course as you grow more experienced you eventually memorize the commands you end up using despite them not having much consistency (git checkout removes files, but it also changes or creates branches for instance).
This is a major pain for people learning Git for the first time and basically everyone have run into these issues, while a more user-friendly tool would've saved so much pain and suffering. There's a reason why most people cling to a Git GUI like their life depends on it.
Being easier to learn and reason about together with better conflict resolution and rebasing are substantial improvements I'd say.
It's a relatively easy thing to adopt something you don't need, when you are the only person involved. But VCS is pretty much in the same category as instant messaging and social network platforms are. In a sense, maybe it is a social network platform. I don't see it happening and I highly doubt I would want it to happed, even if I knew this jj stuff better.