It uses it when you use the git backend, but not when you don’t.
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.
Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git.
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.
Not working on it (yet), but I wish the jj <-> github story was a little more ergonomic.
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.
https://github.com/LucioFranco/jj-spr is one way to get stacked diffs on GitHub with jj, but also GitHub has at least claimed on X that native stacked diffs is coming so we'll see how that goes!
Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN)
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.
you have the audacity to play the victim card for Israil after the whole world -including you- witnessed live and in HD for over two years what they have done to Gaza poeple?
Do you think Israeli civilians shouldn't be able to defend themselves from Hamas' rockets? If yes - why? If not - what exactly is it that you find so problematic with the parent post?
What you don't understand is the carnage in Gaza is self-inflicted. Hamas attacked knowing what would happen. And knowing that every dead Palestinian was a weapon to use against Israel in the propaganda war. Thus they did everything they could get away with to maximize dead Palestinians.
I'd strongly encourage MIT/Apache2 over GPL, unless you believe that you're writing something that has a real likelihood to to be monetized and want to specifically prevent that problem.
A very real example of that is that Ratatui (MIT license) and Codex (Apache2). I feel comfortable reading and using code and ideas from either side and have them influence the design of the other side [1][2]. I don't feel comfortable in the same way reading any GPL licensed code (2 or 3) due to the inherent legal risk that entails.
Your personal views on software freedoms definitely trump my personal opinion as a developer here, so I'm not too stressed if you disagree with this. A solid amount of crates in the rust ecosystem are MIT or Apache 2 (or both), and I really encourage authors of new libs, apps, to choose the same licenses for giving back in the same spirit.
I'm sure we all assumed that they came from the same codebase, but I don't think any of us were expecting the features to be shipped to both platforms and disabled at runtime as required. I expected a common codebase with the iPadOS features disabled at compiletime for iOS, and vice versa.
reply