4 ms·

Git has lots of downsides, lots of power that forces you to work hard for things that should be easy. jj is better. If it's backed by git and doesn't break an

Git has lots of downsides, lots of power that forces you to work hard for things that should be easy. jj is better. If it's backed by git and doesn't break anyone else working on the repo, what's the problem?

pbh101 2y ago
A useful question is ‘how much better?’ For so many reasons, SVN to Git was a no-brainer but still constituted significant migration costs for existing teams and codebases: training, retooling, high-fidelity data transfer (you retained the commit history, right?). For a tool with such wide adoption, motivating an ecosystem to move where there are many actors with different incentive structures, some of them will look and say ‘30% better isn’t even close to sufficient to spend time and $$$ on this. I would need ~10x better and/or a gain of altogether new capabilities impossible in previous tool to motivate that.’ It’s great that jj can be used independently without needing the whole ecosystem to move today, but once/if that part changes I’d expect it to be a long slog towards re-standardization if ever. But jj likely already fully anticipated this given its compatibility with the Git wire protocol in the first place and I doubt it would ever give that up given the current landscape.
- steveklabnik 2y ago
  Given Jj has pluggbale backends, with two production ready ones and one test one, even if they did want to give it up, that would mean moving it to a third party, so like, yeah, not going away.
  - pbh101 2y ago
    Agree with current state but I mean who knows how ecosystem might evolve… one vendor might ascend and embrace extend and extinguish on a separate backend. I think it unlikely, but it’s a possible path.
usrbinbash 2y ago
> 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.
motorest 2y ago
> Git has lots of downsides, lots of power that forces you to work hard for things that should be easy. Care to point one concrete example?
- underdeserver 2y ago
  I'm working on a change when a review comment comes in. I want the review ping-pong to move fast so I want to pause my work on the current branch and address the review comment. I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it. With jj, you run `jj edit`.
  - motorest 2y ago
    > I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it. You do: git commit -m "wip" Then, if you wish to undo the commit then: git reset HEAD If instead you want to update your commit with additional changes: git commit --amend Seriously, why are you guys advocating for replacing a tool when the problems you're actually experiencing are due to your inabilility to learn the basics of it? I mean, is jj edit any better than git commit --amend ? Does git commit --amend require more cognitive load to understand?
    - JTyQZSnP3cQGa8B 2y ago
      The git command line is an awful thing that should have been fixed a long time ago. jj fixes it while staying compatible. Your examples are laughable because most serious commands are way more complicated than that and again jj fixes that gracefully.
      - motorest 2y ago

pbh101 2y ago

A useful question is ‘how much better?’ For so many reasons, SVN to Git was a no-brainer but still constituted significant migration costs for existing teams and codebases: training, retooling, high-fidelity data transfer (you retained the commit history, right?). For a tool with such wide adoption, motivating an ecosystem to move where there are many actors with different incentive structures, some of them will look and say ‘30% better isn’t even close to sufficient to spend time and $$$ on this. I would need ~10x better and/or a gain of altogether new capabilities impossible in previous tool to motivate that.’ It’s great that jj can be used independently without needing the whole ecosystem to move today, but once/if that part changes I’d expect it to be a long slog towards re-standardization if ever. But jj likely already fully anticipated this given its compatibility with the Git wire protocol in the first place and I doubt it would ever give that up given the current landscape.

steveklabnik 2y ago
Given Jj has pluggbale backends, with two production ready ones and one test one, even if they did want to give it up, that would mean moving it to a third party, so like, yeah, not going away.
- pbh101 2y ago
  Agree with current state but I mean who knows how ecosystem might evolve… one vendor might ascend and embrace extend and extinguish on a separate backend. I think it unlikely, but it’s a possible path.

usrbinbash 2y ago

> 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.

motorest 2y ago

> Git has lots of downsides, lots of power that forces you to work hard for things that should be easy. Care to point one concrete example?

underdeserver 2y ago
I'm working on a change when a review comment comes in. I want the review ping-pong to move fast so I want to pause my work on the current branch and address the review comment. I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it. With jj, you run `jj edit`.
- motorest 2y ago
  > I can either stash my changes, which requires keeping a mental model of the stash queue (what if the review comments took a while and I started working on something else?) or a "wip commit", which you need to know, and you need to know how to reset and force push if you accidentally push it. You do: git commit -m "wip" Then, if you wish to undo the commit then: git reset HEAD If instead you want to update your commit with additional changes: git commit --amend Seriously, why are you guys advocating for replacing a tool when the problems you're actually experiencing are due to your inabilility to learn the basics of it? I mean, is jj edit any better than git commit --amend ? Does git commit --amend require more cognitive load to understand?
  - JTyQZSnP3cQGa8B 2y ago
    The git command line is an awful thing that should have been fixed a long time ago. jj fixes it while staying compatible. Your examples are laughable because most serious commands are way more complicated than that and again jj fixes that gracefully.
    - motorest 2y ago