it is worth noting that Jujutsu uses Git’s storage, networking, and ecosystem.
Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.
To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.
Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj.
But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for?
Just really curious about this new world with some better solutions to git.
I liked pijul a bunch too but lack of compat with git meant I can't use it for work... Haha real sad moment right there.
Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff.
ezyang's gh stack was pretty useful, if a little bit fragile [0] and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool.
[0] https://github.com/ezyang/ghstack
I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.
The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.