> 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.
> 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.
I'm not sunshowers, but I think the point isn't the exact number or a way of measuring it. For example, the reason I prefer to write Rust over C++ is not that I have measured it to be 2.6X faster for me to work with. My interpretation of what sunshowers was saying was more like "'technically better' can be enough, depending on much better it is, and I think Jujutsu is a big enough improvement [for me] that it's worth it".
For me, the important metric here is the intersection of two things: number of concepts, and power. I moved from svn to git relatively early in Git’s life; I started using GitHub in 2008. I’ve loved git for a long time.
jj has the ability to do everything git can, but has fewer primitives that are factored better. This means it is easier to use, while still retaining the ability to do anything.
I don’t know if that’s 10x, but it’s good enough for me that I’m never using git again.
I mean 10% and 10x metaphorically, the point being jj is much much much much better than Git. But I wouldn't be surprised if a dev can go from zero to being able to do complex history editing in jj, 10x faster than the same in Git.
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.