Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
stouset
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
33 ms
·
631.
▲
by
stouset
1y ago
jj uses a TUI for this that lets you navigate the entire set of changes.
632.
▲
by
stouset
1y ago
For 1, gerrit and jj have recently collaborated to standardize on a commit footer where stable revision IDs are encoded in the jj style. This landed in a jj release a few months back. I assume it’s live in gerrit now too.
633.
▲
by
stouset
1y ago
It is evangelism. Unabashedly. I think the Plato’s cave analogy is honestly apt. Git was fine. I used git for ages. I loved its underlying model, and I think it’s brilliant. But it has a lot of sharp edges and a lot of tasks that are pain
634.
▲
by
stouset
1y ago
I still know git. I work at entirely git shops. Nobody has ever come to me with a problem I’ve caused, but people have come to me to ask how to switch. I am also the guy who gets asked with doing crazy git things when the need comes up. I
635.
▲
by
stouset
1y ago
Yep! And it makes it convenient even when you need to make changes or add new commits onto A. B is constantly stitched up to remain a child of A and incorporate its fixes. It also makes it simple and easy to split B and A apart such that bo
636.
▲
by
stouset
1y ago
> Reviewers don't want to navigate 33 tiny PRS either. As opposed to one 33-change PR? Yes, absolutely yes they do. I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when
637.
▲
by
stouset
1y ago
What if you could have the best of both worlds? Where the developers at that other company could “take out the trash” amidst one PR, jj makes it trivial to carve off each of those fixes into their own separate PR. It’s no more work than mak
638.
▲
by
stouset
1y ago
Let’s say you’ve checked out a new branch and done a bunch of work over the course of the last two hours. You’ve added a new feature. In doing that, you’ve also fixed four unrelated bugs, clarified the documentation for a method you needed
639.
▲
by
stouset
1y ago
> I can nuke an fs snapshot in a single line of bash if I accidentally leak something, and fs snapshots don't contribute to the slowness of a big repo. Leaking isn’t really a concern; none of these ephemeral commits ever leave your
640.
▲
by
stouset
1y ago
Yes, there are a million weird band-aids that git has grown over time. Some of them work better than others. Or we could just not have the problems to begin with.
641.
▲
by
stouset
1y ago
For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, bu
642.
▲
by
stouset
1y ago
Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of reba
643.
▲
by
stouset
1y ago
Yes! I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM'
644.
▲
by
stouset
1y ago
These are all really excellent points, and well worth calling out.
645.
▲
by
stouset
1y ago
FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box. > I’ve only tried it solo hobby projects. If I can surmise a bit, this is probably why it's never felt &quo
646.
▲
by
stouset
1y ago
The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a st
647.
▲
by
stouset
1y ago
> In other words, I actually understand git, so I don't really need Jujutsu. This is kind of a poor take. By all means use what you prefer! But understanding git and knowing the "right" way to use it doesn't make jj o
648.
▲
by
stouset
1y ago
I'll be honest, it's been so long at this point since I've used git that it's hard for me to remember the exact details of many of the challenges. I know that I avoided a lot of workflows I wanted to do because of the
649.
▲
by
stouset
1y ago
> What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. Yes, it's "committed", but that doesn't mean all that much. I have the fs
650.
▲
by
stouset
1y ago
I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of na
651.
▲
by
stouset
1y ago
Note also that jj does have branches, they are just anonymous. You don't checkout a branch or edit a branch, you edit a revision or make a new one. One revision with multiple children is a branching point, one revision with multiple
652.
▲
by
stouset
1y ago
I am not a magit user but from doing a little bit of reading, all of these commands are essentially first-class citizens in jj. Spinoff seems to be `jj split` (or in most cases literally nothing because the default is to edit a new, empty
653.
▲
by
stouset
1y ago
For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who e
654.
▲
by
stouset
1y ago
There's really no cost to trying it out on an existing project with other people. It natively interoperates with git. Nobody needs to know you're using something different, and you can always fall back to using git commands if you
655.
▲
by
stouset
1y ago
Git is nearly universal, so highlighting the areas where jj makes things that are painful in git trivial and obvious isn't exactly a bad strategy. It's also worthwhile pointing out that it is interoperable with git, so your compan
656.
▲
by
stouset
1y ago
Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the
657.
▲
by
stouset
1y ago
It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a
658.
▲
by
stouset
1y ago
In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision. I tend to do a bunch of work then split into small, bite-sized revisions. Often I split som
659.
▲
by
stouset
1y ago
Nobody is putting words in your mouth. They are reacting directly to the absolutely bonkers statements you are making that there is ethically no difference between killing 350 million live, healthy male chicks every year and preventing thos
660.
▲
by
stouset
1y ago
I still script in bash and I still know bash. It’s just not that big an ordeal to code-switch between the two.
More ›