I like the idea of ratchets, but the implementation needs to be good for them to work nicely.
> If it counts too few, it also raises an error, this time congratulating you and prompting you to lower the expected number.
This is a pain and I hate that part. It's one of the things that isn't even a big deal, but it's regularly annoying. It makes leaving things in simpler than removing them - the good act gets punished.
One way to make this better is to compare the count against the last merge base with the main branch. No need to commit anymore. Alternatively you can cache the counts for each commit externally, but that requires infra.
> AI can be a very effective tool for education if used properly. I have used it to create a ton of extremely useful visualizations
I feel like this is still underappreciated. Awesome meaningful diagrams with animations that I would take me days to make in a basic form can now be generated in under an hour with all the styling bells and whistles. It's amazing in practice because those things can deliver lots of value, but still weren't worth the effort before. Now you just tell the LLM to use anime.js and it will do a decent job.
You may not be in the right state, but the point of that part of the website is that it's a donation link. It will drive some people to help. If it's at the cost of some others getting grumpy about too much messaging... that's probably still worth it.
The good sense is your judgement. At some point a real, direct, disruptive protest is going to be the right solution for a big enough group of people. Peaceful protests are just a "we're starting to get there" signal. It's not like politicians normally say "gee, lots of people don't like how I abuse power, I guess I'll stop now". It's all about being collectively upset enough about status quo.
Don't question in an aggressive way. But feel free to ask why things are the way they are. If you do it while they have time and if they're good senior, they'll be happy to show you all the skeletons in the closet and explain why things are the way they are.
It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.
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.
> if there is a background level of foreign agent activity they accept
Yup, there's constantly a number of known spies in pretty much all countries. If all were ejected, the other country would do the same to their spies and monitoring compliance with projects would become harder - so it seems in everyone's interest to not be too strict. See for example https://johnsontr.github.io/assets/files/spies_current.pdf
Also there's the idea of "the optimal amount of fraud is non-zero" which generalises to lots of things - including this one.
> If it counts too few, it also raises an error, this time congratulating you and prompting you to lower the expected number.
This is a pain and I hate that part. It's one of the things that isn't even a big deal, but it's regularly annoying. It makes leaving things in simpler than removing them - the good act gets punished.
One way to make this better is to compare the count against the last merge base with the main branch. No need to commit anymore. Alternatively you can cache the counts for each commit externally, but that requires infra.
reply