Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

391–400 of 552 posts

Re: Jujutsu for busy devs

#391

Post by stouset »

1718627440 wrote: post #223
stouset wrote: post #148

Earlier quoted context omitted.

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 rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch. Rebases also don't play nicely with stacked branche…

> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks You can use git commit --fixup to record what you want to change in an earlier commit. > start over from scratch rerere > Branches based off your original changes don't get rewritten As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.

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.

Re: Jujutsu for busy devs

#392

Post by mpyne »

steveklabnik wrote: post #386
mpyne wrote: post #384

Earlier quoted context omitted.

I think `git add -p` and its friends are another thing I'd point to for this. I've never really struggled too hard to get git commits into different branches for review, but if you've put unrelated changes into the same working dir, you'll want `git add -p` to sort them out into multiple commits. Note there are corresponding `-p` flags for things like git-restore and git-reset as well.

jj tends to use -i for 'interactive' to do what you do with -p in most git commands. It is in fact a great tool, jj makes doing this even easier.

I'm sure it's great but I don't have the problems with git that others apparently do, so as to make it worth switching to a whole new mental mode of source code management.

At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.

Re: Jujutsu for busy devs

#393

Post by stouset »

ants_everywhere wrote: post #286
stouset wrote: post #66

Earlier quoted context omitted.

> 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 fsmonitor feature enabled that continually watches my repos as I edit files in them. This means that over the course of a coding session, the revision I'm working on has probably pointed at dozens or more ephemeral under…

I don't mind the workflow of selecting what you want at a later time, but my concern is with having changes visible to the local repo database automatically. If you like it that way, that's cool with me. But to me personally I'd rather have the filesystem doing snapshots and not comingle fs snapshots with VCS. I can nuke an fs snapshot in a single line of bash if I accidentally leak something, and fs snapshots don't…

> 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 local machine. I have used jj on a very large monorepo with > 10yr of commits, and I never noticed a performance issue.

jj was literally created by Googlers at Google for the purpose of being used at Google. I have no idea how that’s going, but it makes me suspect that it works better at that use-case than you’re giving it credit for.

Re: Jujutsu for busy devs

#394

Post by packetlost »

sunshowers wrote: post #389
packetlost wrote: post #370

Earlier quoted context omitted.

I've had maybe 3-4 occasions in my entire career where I was working with a rebase large enough where it took multiple sittings (every single one sucked badly). I'm not going to argue that it's not something that comes up, but I will say that if it's common, your workflow is probably too chaotic for me. That being said, you can still do that in git (see sibling comment to this one), but it is more involved. IMO that'…

Well for me it's happened hundreds of times. Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack. > IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good. Nah, it's wonderful. You see it as chaotic and jumpy because the…

> Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack

I think this is what `git rebase --edit-todo` is for.

>Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy.

Fair enough. `jj` probably isn't right for me, but I'm happy it works well for you!

Re: Jujutsu for busy devs

#395

Post by sunshowers »

packetlost wrote: post #394
sunshowers wrote: post #389

Earlier quoted context omitted.

Well for me it's happened hundreds of times. Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack. > IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good. Nah, it's wonderful. You see it as chaotic and jumpy because the…

> Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack I think this is what `git rebase --edit-todo` is for. >Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. Fair enough. `jj` probably isn't right…

Been a long time since I used git, but --edit-todo only changes what's still to come, right? It doesn't let you go back and edit earlier commits in the stack.

Re: Jujutsu for busy devs

#396

Post by stouset »

mpyne wrote: post #384
sesm wrote: post #359

Earlier quoted context omitted.

> It's also very helpful if you're the kind of developer who makes lots of unrelated changes in a single coding session, and wants all those changes to be in parallel branches that can be reviewed and merged independently. Git has worktrees for that. If a parallel change is done in a separate worktree, it can be built and tested independently, which, I guess, is important for kernel developers, who are the initial ta…

I think `git add -p` and its friends are another thing I'd point to for this. I've never really struggled too hard to get git commits into different branches for review, but if you've put unrelated changes into the same working dir, you'll want `git add -p` to sort them out into multiple commits. Note there are corresponding `-p` flags for things like git-restore and git-reset as well.

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 to use, and rewritten another function to be more performant.

You could push this all as six commits on one branch. PR reviewers will now have to figure out what parts are related to what, or read each commit one-by-one. If someone wants changes to one of these commits, your entire branch is held up.

Or you could split these six different commits out to each be directly on `main` and make a PR for each of them. They can be tested in CI, reviewed, and merged in isolation.

The latter is far better. You can do it in git, but it’s not exactly fun. It is trivial in jj.

Re: Jujutsu for busy devs

#397

Post by exographicskip »

nchmy wrote: post #284
beng-nl wrote: post #164

Earlier quoted context omitted.

Wow, that does sound like a big improvement. My git commits are, when not forced to be otherwise, very sloppy, even though I’d prefer them to be neatly self contained. But as you imply, there is friction to making these in git, while making lots of unrelated changes in a single coding session. As an example of another ‘unnecessary’ switch, Pip with venvs was also completely solving all my Python dependency problems.…

You'll love jj, as you've already been able to see the the light with new tooling like uv. Jj is to git what uv is to other python tooling. Check out jjui as well, which makes jj even better. https://github.com/idursun/jjui https://mise.jdx.dev is equally as revelatory as jj and uv

mise is awesome. Put it off far too long after a bad first experience. Now I'll never go back to asdf

Re: Jujutsu for busy devs

#398

Post by steveklabnik »

mpyne wrote: post #392
steveklabnik wrote: post #386

Earlier quoted context omitted.

jj tends to use -i for 'interactive' to do what you do with -p in most git commands. It is in fact a great tool, jj makes doing this even easier.

I'm sure it's great but I don't have the problems with git that others apparently do, so as to make it worth switching to a whole new mental mode of source code management. At least uv solved real problems I was having with Python package management, but for my own personal usage git is 99% aligned with what I need.

I didn’t have problems with git either.

jj just makes all of the stuff I liked to do with git easier and faster, and lets me do some things you can’t do with git.

But you should use the tools you want to use.

Re: Jujutsu for busy devs

#399

Post by Levitz »

nchmy wrote: post #296
esperent wrote: post #112

Earlier quoted context omitted.

> there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. This sounds exactly like something a person evangelizing it would say.

The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? What other tools do people do that for? Not many. I see the most similar language and behaviour with regards to uv, which similarly revolutionized/simplified python tooling. Likewise mise, which makes it similarly frictionless to install and manage tooling and their versions across projects and system-wid…

>The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool?

To make a point? To prove that "they are right"? People do this constantly, tools, libraries, languages... All the time really.

Re: Jujutsu for busy devs

#400

Post by stouset »

sethammons wrote: post #168
stouset wrote: post #154

Earlier quoted context omitted.

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, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated chan…

Nice commits can really tell a development story that makes reviews easier. That said, I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release. A very, very large problem at five out of six companies I have worked at is casual code improvement and refactoring. Devs would say, "we will ad…

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 making them separate commits.

People don’t do this in git because it’s a hassle. So you either get cleanup that never comes because each branch needs to know in advance what work it’s going to do or you get omnibus PRs that do twenty different things.

There’s a better way, and it lets you have clean history and developers can fix things they run into along the way.

Post reply on HN