I think you've straight up reinforced my example. The end result is the same, but the way to get there is different.
Depending on what your destination is, a different tool might ultimately turn out to be better for the job. Even if they're both representing their state in a compatible manner on disk.
You're probably just not realizing that the way you interact with git isn't necessarily how everyone does - and that other people might have usecases that you've never thought about... Because you're not in their situation. So you're only seeing one way to reach the destination, which is why the one tool always looks like the correct choice.
To be clear, my current day job really wouldn't get any value out of any of these features either. We're doing simple trunk development on various repositories with roughly 5 authors providing commits.
Almost no merge conflicts, the most anyone does is git blame to figure out when the line was edited etc. under these circumstances, commits are essentially fire and forget and you're fine only interacting with the repository through your ide even.
Nobody, including you, have produced an example of a workforce that's substantially easier due to gits model.
Either gits design is unnecessarily complex, or there should be a pay off to the complexity somewhere. Some flavor you can't get, or can't get easily, with jj.
I wouldn't need these features either, but I believe teaching jj to beginners will be easier than teaching git. This is further evidence that the problem is git, not the problem space and the need for different workflows: If a different set of concepts serves both power users and beginners better, at what point do we stop pretending that it's all just tradeoffs?
I’m working solo on a project, with trunk based development. I still find jj nicer to use than git. I do do pull requests but just to ensure that CI passes on every commit.
I think you've straight up reinforced my example. The end result is the same, but the way to get there is different.
Depending on what your destination is, a different tool might ultimately turn out to be better for the job. Even if they're both representing their state in a compatible manner on disk.
You're probably just not realizing that the way you interact with git isn't necessarily how everyone does - and that other people might have usecases that you've never thought about... Because you're not in their situation. So you're only seeing one way to reach the destination, which is why the one tool always looks like the correct choice.
To be clear, my current day job really wouldn't get any value out of any of these features either. We're doing simple trunk development on various repositories with roughly 5 authors providing commits.
Almost no merge conflicts, the most anyone does is git blame to figure out when the line was edited etc. under these circumstances, commits are essentially fire and forget and you're fine only interacting with the repository through your ide even.