> barely ever come up in git
Just because you don't run into that problem very often doesn't mean that other people, with different roles and workflows don't run into that problem more frequently.
For now. At some point, it may want to run features incompatible with git, and what happens then?
> nd people that don't understand git but do understand JJ can just run JJ.
And how many such people would you say are there? I am willing to bet that the vast majority of jj users know how to use git very well, and given the adoption of git, that is unlikely to change.
Secondly, git isn't just run by people, its run by scripts, pipelines, automated systems. git commands live in configurations, and elsewhere. Its a common language for how VCS works, not just a command line tool.
> Just because you don't run into that problem very often doesn't mean that other people, with different roles and workflows don't run into that problem more frequently.
It also doesn't mean that they do.
For now. At some point, it may want to run features incompatible with git, and what happens then?
Then we raise issue. But I don't have a problem with what someone else wants to run on their computer.
Neither do I. This discussion isn't about what someone else runs or doesn't run on their computers. By all means, run `jj`.
Or use `fossil`[1], which I maintain is technically superior to both `git` and `jj` (if you disagree, show me another VCS that also gives me a ticketing system, wiki, documentation system, forum and webui, all from a single executeable that allows me to set everything up with a few command line invocations ;-))
Primarily jj is different. And a lot of the "problems" it solves barely ever come up in git. And when they come up, its usually as "difficult" as "google the solution and enter the commands". And worst case scenario, someone has to manually copy paste some files around.
If this happened every day, I'd agree that we need a different system. But it doesn't.
In short, the situations where jjs advantages can really shine, and the advantages in these situations are simply not common enough / important enough to justify the headache of switching the world over to another VCS.
In an ideal world, "the better" solution wins.
In a pragmatic world of limited resources, "better" on its own is not enough. The differential between the new and the old solution has to be large enough to offset the cost of switching, and the more entrenched the existing solution is, the higher that cost will be.