4 ms·

> 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

> 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.
    - sunshowers 2y ago
      > 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. 10% better isn't. 10x better is. Jujutsu is 10x better.
      - usrbinbash 2y ago
        And this assumption is based on ... what exactly?
        sunshowers 2y ago
        My long professional history working on source control.
- KingMob 2y ago
  Both things are true at the same time. Git is wildly popular, and a large part of that is its solid and fast technical underpinnings. Unlike its open source predecessors (svn/cvs), it excelled at distributed development. At the same time, git also has a terrible CLI, combined with unnecessarily complexity like staging, stashes, rebase states, etc. This has been true from the beginning. Mercurial was built at the same time (also by a linux kernel dev!), and was generally considered to have a much better CLI and mental model. I think hg lost out despite that because it was slower than git, and didn't have Linus behind it.

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.
  - sunshowers 2y ago
    > 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. 10% better isn't. 10x better is. Jujutsu is 10x better.
    - usrbinbash 2y ago
      And this assumption is based on ... what exactly?
      - sunshowers 2y ago
        My long professional history working on source control.
KingMob 2y ago
Both things are true at the same time. Git is wildly popular, and a large part of that is its solid and fast technical underpinnings. Unlike its open source predecessors (svn/cvs), it excelled at distributed development. At the same time, git also has a terrible CLI, combined with unnecessarily complexity like staging, stashes, rebase states, etc. This has been true from the beginning. Mercurial was built at the same time (also by a linux kernel dev!), and was generally considered to have a much better CLI and mental model. I think hg lost out despite that because it was slower than git, and didn't have Linus behind it.