5 ms·

> jj is better 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" a

> jj is better 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.

fragmede 2y ago
But the world doesn't have to switch over to a new RCS. JJ works with git servers, so git can continue being the server, and people that don't understand git but do understand JJ can just run JJ. > 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.
- usrbinbash 2y ago
  > JJ works with git servers 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.
  - fragmede 2y ago
    >> > JJ works with git servers 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.
    - usrbinbash 2y ago
      > 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 ;-)) [1]: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki

fragmede 2y ago

But the world doesn't have to switch over to a new RCS. JJ works with git servers, so git can continue being the server, and people that don't understand git but do understand JJ can just run JJ. > 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.

usrbinbash 2y ago
> JJ works with git servers 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.
- fragmede 2y ago
  >> > JJ works with git servers 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.
  - usrbinbash 2y ago
    > 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 ;-)) [1]: https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki