Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time.
For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns.
We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.
IMO Subversion was never as much of a standard as git. I saw a lot of software that still used CVS back then, and even more that didn't do version control beyond versioned source tarballs.
I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git.
Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it.
Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.
Not necessarily. I used jj for a couple of weeks and found it to be a complete waste of time.
For an advanced user, it did not offer anything I cannot quickly solve in git. Which is probably the wrong thing to optimize in the first place, because even though I frequently rewrite history and split commits during normal worklfow, it takes so little time that improving something else would yield greater returns.
We (not royal we) don't usually go out of our way repeating negative experiences with these tools, so you build a very skewed view of their adoption.
Their opinion is great, why do you feel like you need to counter it with [but, but jj is for the clean masses, not the unclean users].
Might be true, but Subversion was also good enough and a de-facto standard.
IMO Subversion was never as much of a standard as git. I saw a lot of software that still used CVS back then, and even more that didn't do version control beyond versioned source tarballs.
I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git.
Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it.
I have deep scars from mercurial lol.