> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.
The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.
Changesets, the op log, first class conflicts, no staging area.
JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.
On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.
The substantial technical difference is that the UI (the "porcelain") of JJ is not backwards-compatible with that of Git, even though it can use git's "plumbing". `jj commit` works differently than `git commit`, and Git can't match that without a similar compatibility break. JJ uses Git's "content-addressed DAG of snapshots" data model in a particularly elegant way, and deletes many redundant commands to achieve that elegance. Git could absolutely delete half of its interface & change much of the rest to get that, but then it'd break lots of scripts & third-party tools. JJ namespaces the UI redesign, which allows breaking that compatibility without breaking everyone's workflow at once. People can switch (or not switch) independently, where a Git UI redesign would have to be adopted by everyone together.
It's trivial that JJ can't do anything `git` can't do, because JJ uses Git as a backend, so everything it does it does via `git`. But Git the project is extremely unlikely to alter `git` the tool to provide JJ's interface, and even if they did via namespacing it (e.g. `git jj commit`, `git jj git init --colocate`, etc.) that'd just be adding even more commands on top of the existing interface with too many commands.
Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.