If you're already super comfortable in git, it's not. I'm saying this as someone who recently converted from git to jj and never wants to go back.
You also don't have to follow what the GP said. I never say `jj describe` before writing code. I write the code then just say `jj commit -m "Foo stuff"`, just like I would in git.
The bigger difference I've noticed is:
1. Switching between changesets just feels more natural than git ever did. If I just run `jj` it shows me my tree of commits (think of it like showing you git's branches + their commits), and if I want to edit the code in one of them I just say `jj edit xyz`, or if I want to create a new commit on top of another one and branch it off in a new direction, I just say `jj new xyz`. It took a little bit for my brain to "get" jj and how it works because I was so used to git's branches, but I'm really enjoying the mental model.
2. `jj undo`. This alone is enough to convert me. I screwed something up when trying to sync something and had a bunch of conflicts I really didn't want to resolve and I knew could have been avoided if I did things differently, but my screwup was several operations ago! So I ran `jj undo`. And ran it again. And again. And again. And then I was back to my clean state several stages ago before I screwed up, despite having made several changes and operations since then. With git? Yeah I could have gotten it fixed and gone back. But every time I've had to do something like that in git, I'm only 25% confident I'm doing it right and I'm not screwing things up further.
3. Rebasing. When I would try to sync git to an upstream GitHub repo that used rebasing for PRs, I would always get merge conflicts. This was because I stack my changes on top of each other, but only merge in one at a time. Resyncing means my PR got a new commit hash, even though none of the code changed, and now git couldn't figure out how to merge this new unknown commit with my tree, even though it was the same commit I had locally, just a different hash. With jj? I never get merge conflicts anymore from that.
Overall the developer experience is just more enjoyable for me. I can't say jj's flow is fundamentally and objectively better than git's flow with branches, but personally and subjectively, I like it better.
In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions.
(Your question is not dumb, BTW. The pithy answer is: UX matters, but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing to get a desired outcome, and that's tricky to express in text. Also there will always be some people for whom a new mental model just doesn't work. That doesn't make them dumb either, at least provided they have the wisdom not to petulantly piss in the cornflakes of those who get a kick out of how much better the new thing works for them.)
I'm glad to hear you never encountered the kind of quagmire that can occur around e.g. non-trivial conflicts while rebasing a chain of git commits. On large enough codebases, those can be common.
I’ve done it multiple times without much effort. Or skill. Really it was a skill issue and I tried things that I thought would work but apparently don’t.
I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!
It's not, you can literally do everything this tool does with Git, and 80% of the features could be replaced with commands in your shell rc file also using vanilla git.
This tool was described perfectly the other day. JJ is the Dvorak of Git. Most people could careless about Dvorak layout, 99.8% of people use qwerty just fine. Those 0.02% though, they're loud, and they want everyone to know how great the reinvention of bread is.
I personally find this is the correct solution, since indexes are over-inflated either way, this brings much needed sanity to the index. Your index is now worth much more or much less based on how you view the AI bubble and you are forced to understand and correct your forward looking investments accordingly.
Passive investments are good, but if taken too far as they clearly have been in the last decade they become a scam. Everyone is SIPing into it, and there is infinite liquidity. Until one big whale finally decides they are booking it, then all hell will break loose on the same damn day.
The issue is what each of the projects considers viable bug if you consider all localized assertion failures possible bugs then that's different from give me something that practically affects users.
Further browsers have a much larger surface area for even minor fuzzing bugs. Curl's much smaller surface area is already well fuzzed and tested.
Chrome has better fuzzing and tests too. Firefox has had fewer resources compared to Google ofc, so understable.
Ofc not saying it wasn't good. But given the LLM costs I find it hard believe it was worth it, compared to just better and more innovative fuzzing which would possibly scale better.
Want to try to do anything more complicated? I have seen a lot of delusional people around, who think their skills are still on the same level, but in interviews they bomb at even simple technical topics, when practical implementations are concerned.
If you don't code ofc you won't be as good at coding, that's a practical fact. Sure, beyond a certain skill level your decline may not be noticeable early because of the years of built-in practice and knowledge.
But considering every year there is so much more interesting technology if you don't keep improving in both hands-on learning and slow down to take stock, you won't be capable of anything more than delusional thinking about how awesome your skill level is.
Ads aren't just for click through, they are for suggestions, and mind share as well.
You can't click on the budweiser logo when watching super bowl ad. But if you sit in your chatgpt window all day then it's probably worth it for advertisers to expect to build familiarity with brands they advertise.
Really depends what the ads are. If they are popups or other intrusive ads the product will just die. If they are subtle hints in the text how are you going to track it. I don't know, I just don't believe in ads, but then again I am dirty commie so who am I to tell you not to
That’s not the point. The point is that brands build awareness through ads that don’t require clicking and this ha effected you whether you want to admit it or not
Your messages are very consistent, it all adds up and makes perfect sense.
I don't care either.
Online I get lots of ads blocked, but not all, I really don't put much effort into it beyond default.
So what if I am "influenced" if it doesn't effect any significant part of my behavior.
One thing I never do is respond with money.
I'm just not a "consumer" so that goes back before the internet.
Sure I see ads thrown at me which keep me aware of those brands but the only buys I make would happen without any ads.
On the rare occasion that I want to make a significant purchase, then I will seek out the ad. Oh the horror !
But I want to see how honest I think it is compared to a number of reviews. It's really pretty neutral since it's just as much me using the ad as the ad using me, plus equally good for knowing what looks good to buy as knowing what brand not to buy.
Then there's the interesting way when an overall economic downturn gets rougher you see ads for things that almost never need advertising for years in a row, or never have before :\
OTOH you also see some of the most trivial stuff that must be flying off the shelf and all you can do is shake your head ;)
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!
We are definitely living in the worst timeline. Lmao
reply