Hacker News new | ask | show | jobs
by SAI_Peregrinus 246 days ago
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.

1 comments

There must be a miscommunication somewhere because your entire comment seems to reinforce rather than refute my point.