4 ms·

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 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.
      - usrbinbash 2y ago
        > Git is up there with Python packaging and regular expressions. Probably. And neither Python Packaging nor regular expressions will be replaced by anything in the next few decades, for the same reasons why `jj` is unlikly to replace git, for the same reason why rust won't replace C, and the same reason why, 20 years from now, people will still have jobs fixing Java and PHP code. > 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. No one is demanding that we stop asking. But as engineers we cannot just consider "better", we also have to consider "practical". And in practical, pragmatic considerations, "technically better" simply isn't enough to displace an entrenched tool. That is a fact, whether people like that or not. I like the ideas of jj. I cheer the development. Will I replace my git with jj in the forseeable future? No. Why? Because pragmatic reasons. To replace an entranched tool that does its job and has wide adoption, a new thing needs to offer absolutely astonishing advantages that become "must-have" just by the merit of their existence. And even then, the ROI of these advantages have to offset all the technical and logistic pain of switching from one to the other. > but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity. There is no shortage of wrappers around git abstracting the nitty gritty to nearly any level of complexity desired. I use vim-fugitive for example. GUI abstractions as well as CLI tools and TUI wrappers exist.
- fragmede 2y ago
  > No one uses jj. Plenty of people use jj. It just doesn't seem like that to you because it's client-side.
  - baq 2y ago
    citation needed. also, define plenty. 1% of git total user base is plenty in nominal terms, I agree, but it's still 1%.
    - fragmede 2y ago
      It's more than zero ie "no one", so GP is obviously wrong.
      - baq 2y ago
        technically correct and completely missed the point.
        martinvonz 2y ago
        It's hard to find that information because neither git nor jj report usage information to a central place. The best I've been able to find is number of Homebrew installs, which says ~1.2k 30-day install for jj and ~162k for git, so it's about 0.7% based on that number. Who knows how many of those installs (of either tool) are actually used as the person's daily driver.
- necauqua 2y ago
  I guess you don't use anything that's not preinstalled on your OS distribution then, lol Jesus, what a hater Maybe one day you'll become self-aware
- sunshowers 2y ago
  It's quite offensive to suggest that the people who built Jujutsu just did it for kicks. "[A] solution desperately looking for a problem"? Really? These are extremely competent engineers, world experts in the field. It might behoove you to be a bit more curious about the deep intellectual lineage behind Jujutsu.

by MrJohz 2y ago

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.
    - usrbinbash 2y ago
      > Git is up there with Python packaging and regular expressions. Probably. And neither Python Packaging nor regular expressions will be replaced by anything in the next few decades, for the same reasons why `jj` is unlikly to replace git, for the same reason why rust won't replace C, and the same reason why, 20 years from now, people will still have jobs fixing Java and PHP code. > 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. No one is demanding that we stop asking. But as engineers we cannot just consider "better", we also have to consider "practical". And in practical, pragmatic considerations, "technically better" simply isn't enough to displace an entrenched tool. That is a fact, whether people like that or not. I like the ideas of jj. I cheer the development. Will I replace my git with jj in the forseeable future? No. Why? Because pragmatic reasons. To replace an entranched tool that does its job and has wide adoption, a new thing needs to offer absolutely astonishing advantages that become "must-have" just by the merit of their existence. And even then, the ROI of these advantages have to offset all the technical and logistic pain of switching from one to the other. > but the UI of Git (i.e. all the commands and surrounding paraphernalia) has a lot of incidental complexity. There is no shortage of wrappers around git abstracting the nitty gritty to nearly any level of complexity desired. I use vim-fugitive for example. GUI abstractions as well as CLI tools and TUI wrappers exist.
fragmede 2y ago
> No one uses jj. Plenty of people use jj. It just doesn't seem like that to you because it's client-side.
- baq 2y ago
  citation needed. also, define plenty. 1% of git total user base is plenty in nominal terms, I agree, but it's still 1%.
  - fragmede 2y ago
    It's more than zero ie "no one", so GP is obviously wrong.
    - baq 2y ago
      technically correct and completely missed the point.
      - martinvonz 2y ago
        It's hard to find that information because neither git nor jj report usage information to a central place. The best I've been able to find is number of Homebrew installs, which says ~1.2k 30-day install for jj and ~162k for git, so it's about 0.7% based on that number. Who knows how many of those installs (of either tool) are actually used as the person's daily driver.
necauqua 2y ago
I guess you don't use anything that's not preinstalled on your OS distribution then, lol Jesus, what a hater Maybe one day you'll become self-aware
sunshowers 2y ago
It's quite offensive to suggest that the people who built Jujutsu just did it for kicks. "[A] solution desperately looking for a problem"? Really? These are extremely competent engineers, world experts in the field. It might behoove you to be a bit more curious about the deep intellectual lineage behind Jujutsu.