Some of it is the historical snobbery that CLI users have for GUI users. I count myself among them. Isn't it way cooler how I can fix my NIC with just three chained bash commands, while the windows users have to navigate 8 levels of dialogues?
But that mentality doesn't leave room for a lot of nuance. Even the most hard core TUI proponents and neovim gurus probably do not use Lynx as their browser (well maybe they use a vibe coded hacker news TUI client instead)
(IIRC the premise was that the underdogs invented something like mipmaps, which I found hard to believe. The core tech was probably already invented by 3d shooters at that time)
> Sure, there are certain features [....] but I don’t see how those couldn’t become part of Pi eventually, either natively or via plugins.
No. I'm done with npm-style dependency sprawl and the supply chain nightmares. Done with plugins, extensions, marketplaces with "install at your own risk" disclaimers.
Give me a opinionated monolith by somebody who has something at stake and doesn't externalize these costs, i.e. a corporation.
Maybe once we live in a world with lean-verified wasm-sandboxed provable-secure software we can get back to installing software written by randos on the internet.
> In 2011, Michael Norton and Dan Ariely asked more than 5,000 Americans how they thought wealth was split between the five fifths of households, and how they would ideally split it. The Companion spreads those five shares across all 100 percentiles of the 2026 wealth total in a smooth curve (Appendix 3). Many different curves fit five numbers, so these two shapes are only illustrations. The actual bars come from percentile-level data. These two curves do not.
AKA it's purely vibes based. The "ideal" distribution more extreme than just dividing GDP and dividing it equally every year because old people naturally have more time to accumulate wealth.
To me the main difference is that there is no staging (so no stashing needed), and conflicts are first class citizens. In practice this means that you can usually halt your work halfway, switch a commit, rebase everything onto head and continue working even if one of the branches off your commit has conflicts. In git you would have to resolve those before the rebase can finish.
Since conflict resolution these days mostly boils down to “hey LLM, resolve conflicts” this is much nicer.
Also jj tracks every change to the repo so undo works much better and is more readable than reflog
My favorite feature is the built-in distinction between what's mutable and what's immutable in my history. I can freely modify any commits I make locally without issue, since no one else would be able to depend on them, but if I push something or fetch it from a coworker, I have the safety of not needing to be careful when doing the equivalent of an amend or rebase because it will fail with an error telling me to use a flag to bypass the immutability protection if that's what I actually want.
Not having to stage changes in lieu of them automatically getting picked up was a bit of a learning curve for me, but now that I've gotten used to it I like it a lot better and I don't think I could go back. The equivalent of the reflog pretty much always has my changes in it if I accidentally lose them without manually saving due to the snapshotting, and I have no need for a stash because commits and branches are essentially just recording a checkpoint rather than being things that feel "heavyweight".
As an added bonus, dealing with conflicts is a lot less annoying because each commit records its conflicts separately, so fixing them doesn't require doing a stateful pipeline of changes in a big rebase; I can just do them piecemeal, in any order I want, and even just check out other stuff and work on them before coming back later if I feel like it.
I was "that guy" who would sometimes have coworkers come for help with git problems (https://xkcd.com/1597/ alt text). I've forgotten most of that knowledge (and all of that muscle memory) and didn't have to learn nearly as much to replace it with the ability to do a lot more with a lot fewer mistakes.
No, jj is not a wrapper around git. It is a source control system of its own that has git as one of at least two production backends. This distinction matters because git wrappers don't tend to have fundamental concepts of their own like the operation and evolution logs.
No, git-branchless is a wrapper around Git. jj is an independent source control system with git compatibility. jj can, and does, function entirely without git.
> I'm not sure where you're getting two production backends from. I guess you're referring to the Google internal one that nobody can use?
But that mentality doesn't leave room for a lot of nuance. Even the most hard core TUI proponents and neovim gurus probably do not use Lynx as their browser (well maybe they use a vibe coded hacker news TUI client instead)
reply