9 ms·

I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost u

I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost universal. It used to be such a mess with all the VCS systems and having to know all of them to commit on various dependencies from different projects. I know that jj can be backed by git. But already it doesn’t need to be. Between this and other projects, I don’t have to squint too hard to see a future that looks like the past. I hope I’m wrong.

baq 2y ago
git is good (good enough even) but not perfect. I’d love to see pijul receive funding for a small team for a couple years but we’ve got what we’ve got. jj’s killer feature is git compatibility, obviously. For now it’s table stakes so we can pretend only git exists.
motorest 2y ago
> I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost universal. This bears repeating. To further frame the importance of this, we've started seeing git being used as the deployment tool of some notable mainstream software projects such as nvm. This is only possible if a VCS becomes ubiquitous and a de-facto standard.
- MrJohz 2y ago
  I think that's actually one of the nice things about JJ in comparison to many others (such as hg or Pijul): it uses Git essentially like a protocol or standard by which it communicates with other systems (and as a file-system standard, like using SQLite or something similar). Essentially, it agrees that Git has become a de-facto standard as a file format and as a protocol, but that doesn't mean it can't have a very different approach to that file format and protocol. It's similar to how HTTP can support a RESTful approach, or GRPC, or GraphQL or whatever else, and all these different systems can build on the same underlying technology.
  - motorest 2y ago
    > I think that's actually one of the nice things about JJ (...) No one uses jj. You need to go way out of your way to install something like jj. It makes no sense to install jj so that they can install something else. Not so with Git. Git is so popular that it comes pre-bundled with other critical software, and some OS distributions even install it by default. Git is a problem-solver. JJ is a solution desperately looking for a problem, for which the right solution is already Git.
    - KingMob 2y ago
      > Git is a problem-solver. Git is also a problem-causer. The existence of sites like ohshitgit.com is testament to that. Git has wasted thousands of developer years with a terrible UI, overly-complex concepts, and lack of basic undo. Some people have internalized, or worked around, git's flaws for so long, they can no longer even see them as such.
      - usrbinbash 2y ago
        > The existence of sites like ohshitgit.com is testament to that. It's a testament to worldwide adoption first and foremost. If `jj` had the same adoption, there would probably be similar sites about it. No tool is perfect, and all have their quirks.
        MrJohz 2y ago
        I'm not sure that's a given. Lots of things have reached worldwide adoption and don't have the reputation that Git has. Bash, for example, is quirks and chaos galore, and I don't think even that has the same level of infamy that Git has. In fact, if we use the metric of "snarky XKCD cartoons about this topic", which is probably a good proxy for how popular a tool is vs how many serious problems it creates, Git is up there with Python packaging and regular expressions. You're right that all tools have their quirks — jj is surely no exception. But it seems like bad engineering and a lack of curiosity to look at the quirks in a tool and not ask if we can do better. How much of a tool's difficulty represents the underlying complexity of the problem it's solving, and how much is just incidental complexity from the tool itself? In this case, I think the core of Git (the underlying model of commits and refs and objects) does a really good job of being exactly what's necessary and no more, but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity. That is, there are simpler and cleaner ways to represent a lot of the stuff that's happening in Git. This, I think, is why a lot of people struggle with Git — not just because version control is hard (although it is), but because Git as a tool is additionally hard on top of that. And I think it's reasonable to look for better ways of doing version control that don't have as much incidental complexity.
fragmede 2y ago
Mostly everyone using the same standard is amazing. Power tools batteries are the glaring failure. Kubernetes gets a lot of shit for being complicated, which it should, because it is, but I'm glad that enough people use it to manage their fleet of computers that I don't have to learn too many special cases for managing fleets of computers. XKCD 927.
globular-toast 2y ago
To generalise a bit, this is really an example of the power of having a common language. I find this is generally undervalued. Having a common language at all is more important than having a "perfect" language. People are too eager to disrupt the language. We instead need to embrace it for what it is, learn to work with it, and only change it in small ways. If you're learning French you don't argue with the language and try to get French people to talk how you want them to talk, you suck it up and do what they do. As with all things it's a trade off: you get to converse with everyone in France, but, yeah, you will have to deal with saying "le parking" etc.
underdeserver 2y ago
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.

baq 2y ago

git is good (good enough even) but not perfect. I’d love to see pijul receive funding for a small team for a couple years but we’ve got what we’ve got. jj’s killer feature is git compatibility, obviously. For now it’s table stakes so we can pretend only git exists.

motorest 2y ago

> I just want to say that we all finally are using mostly the same VCS and that is actually an undervalued, beautiful thing. An actual “standard” that is almost universal. This bears repeating. To further frame the importance of this, we've started seeing git being used as the deployment tool of some notable mainstream software projects such as nvm. This is only possible if a VCS becomes ubiquitous and a de-facto standard.

MrJohz 2y ago
I think that's actually one of the nice things about JJ in comparison to many others (such as hg or Pijul): it uses Git essentially like a protocol or standard by which it communicates with other systems (and as a file-system standard, like using SQLite or something similar). Essentially, it agrees that Git has become a de-facto standard as a file format and as a protocol, but that doesn't mean it can't have a very different approach to that file format and protocol. It's similar to how HTTP can support a RESTful approach, or GRPC, or GraphQL or whatever else, and all these different systems can build on the same underlying technology.
- motorest 2y ago
  > I think that's actually one of the nice things about JJ (...) No one uses jj. You need to go way out of your way to install something like jj. It makes no sense to install jj so that they can install something else. Not so with Git. Git is so popular that it comes pre-bundled with other critical software, and some OS distributions even install it by default. Git is a problem-solver. JJ is a solution desperately looking for a problem, for which the right solution is already Git.
  - KingMob 2y ago
    > Git is a problem-solver. Git is also a problem-causer. The existence of sites like ohshitgit.com is testament to that. Git has wasted thousands of developer years with a terrible UI, overly-complex concepts, and lack of basic undo. Some people have internalized, or worked around, git's flaws for so long, they can no longer even see them as such.
    - usrbinbash 2y ago
      > The existence of sites like ohshitgit.com is testament to that. It's a testament to worldwide adoption first and foremost. If `jj` had the same adoption, there would probably be similar sites about it. No tool is perfect, and all have their quirks.
      - MrJohz 2y ago
        I'm not sure that's a given. Lots of things have reached worldwide adoption and don't have the reputation that Git has. Bash, for example, is quirks and chaos galore, and I don't think even that has the same level of infamy that Git has. In fact, if we use the metric of "snarky XKCD cartoons about this topic", which is probably a good proxy for how popular a tool is vs how many serious problems it creates, Git is up there with Python packaging and regular expressions. You're right that all tools have their quirks — jj is surely no exception. But it seems like bad engineering and a lack of curiosity to look at the quirks in a tool and not ask if we can do better. How much of a tool's difficulty represents the underlying complexity of the problem it's solving, and how much is just incidental complexity from the tool itself? In this case, I think the core of Git (the underlying model of commits and refs and objects) does a really good job of being exactly what's necessary and no more, but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity. That is, there are simpler and cleaner ways to represent a lot of the stuff that's happening in Git. This, I think, is why a lot of people struggle with Git — not just because version control is hard (although it is), but because Git as a tool is additionally hard on top of that. And I think it's reasonable to look for better ways of doing version control that don't have as much incidental complexity.

fragmede 2y ago

Mostly everyone using the same standard is amazing. Power tools batteries are the glaring failure. Kubernetes gets a lot of shit for being complicated, which it should, because it is, but I'm glad that enough people use it to manage their fleet of computers that I don't have to learn too many special cases for managing fleets of computers. XKCD 927.

globular-toast 2y ago

To generalise a bit, this is really an example of the power of having a common language. I find this is generally undervalued. Having a common language at all is more important than having a "perfect" language. People are too eager to disrupt the language. We instead need to embrace it for what it is, learn to work with it, and only change it in small ways. If you're learning French you don't argue with the language and try to get French people to talk how you want them to talk, you suck it up and do what they do. As with all things it's a trade off: you get to converse with everyone in France, but, yeah, you will have to deal with saying "le parking" etc.

underdeserver 2y ago

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.