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

381–390 of 552 posts

Re: Jujutsu for busy devs

#381

Post by riwsky »

MrJohz wrote: post #182
dzaima wrote: post #135

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. I was extremely hostile to this aspect of jj too, but I've settled on a workflow where @ (i.e. the change/commit referring to the working copy) is always the same, named ".WIP: …", and as such is clearly never supposed to break out of the local system, and can never accidentally get pushed…

If you leave the WIP head change blank, i.e. don't give it a description at all, then JJ will block you from pushing it unless you pass a specific flag, which is useful for sanity checking this sort of stuff. You might be able to configure JJ to also block commits with certain descriptions as well, which might be useful in your case.

You indeed can: https://jj-vcs.github.io/jj/latest/config/#set-of-private-co...

Re: Jujutsu for busy devs

#382

Post by IshKebab »

Zambyte wrote: post #354
stavros wrote: post #268

Earlier quoted context omitted.

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing thing…

> because there's no single thing that you can do with jj that you can't with git. - jj undo, jj op restore, and jj --at-op to reset or view the repo at a previous state - create multiple directories (workspaces) backed by a single repository at different commits These are the only things I can think of off the top of my head that you can do with jj that you can't do with git.

> create multiple directories (workspaces) backed by a single repository at different commits

This is `git worktree`.

They don't work with submodules but submodules are a disaster that should be avoided anyway so probably no big loss there.

Re: Jujutsu for busy devs

#383

Post by benoau »

palata wrote: post #143
stouset wrote: post #33

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 evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim , the b…

> You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff

Wit the added bonus that "bim" won't remain popular enough to sustain its development for long, so "bim" users have to switch to the fork "bbim" in 2 years, that won't remain popular enough to sustain its development for long...

Re: Jujutsu for busy devs

#384

Post by mpyne »

sesm wrote: post #359
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…

> 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.

Re: Jujutsu for busy devs

#385

Post by steveklabnik »

sesm wrote: post #359
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…

> 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…

jj also has worktrees, though they're called workspaces.

They're useful, but they're not really what your parent is talking about, your parent is talking about a workflow where you realize you've want to break up your work after the fact, rather than setting out to do it that way from the start.

Re: Jujutsu for busy devs

#386

Post by steveklabnik »

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.

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.

Re: Jujutsu for busy devs

#387

Post by 1718627440 »

baq wrote: post #376
1718627440 wrote: post #223

Earlier quoted context omitted.

> 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.

> You can use git commit --fixup to record what you want to change in an earlier commit. jj just does it correctly by default. > rerere jj just does it correctly by default. > As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto. jj just does it correctly by default. defaults matter.

>> git commit --fixup

> jj just does it correctly by default.

JJ adds changes to random old commits instead of the newest one? Yikes.

> rerere by default

Takes space and time.

> --update-refs by default

Maybe sensible, don't need it most of the time.

Re: Jujutsu for busy devs

#388

Post by KingMob »

1718627440 wrote: post #267
KingMob wrote: post #252

Earlier quoted context omitted.

That's still true in jj, too. But instead of commits, most of the time you're working with (the not greatly-named) "changes", which are a conceptual history of related commits. E.g., a single change ID points to the most recent commit in a list. As long as you keep editing on a change, it keeps accumulating commits under the hood. When you move to another change (via `jj commit`, `jj new`, etc), all your new commits…

Ah, so when people here talk about changing commits they are actually talking about changing changes (nicely named, indeed)? What happens when you merge or split changes with the change history? It sounds a bit like applying a VCS on top of a VCS.

Yeah, I love jj, but I'm not a fan of that naming. It threw me for a loop for the first couple months.

I'm not sure what happens, but I suspect a merge would create a single merge commit with the tips of the parents' histories, and then add new commits from there on.

A split is probably conceptually similar to making two new branches, except each of the new commits gets one of the branch tips. Really just guessing here, I have no idea if that's how it works, or if they share commits or not.

Re: Jujutsu for busy devs

#389

Post by sunshowers »

packetlost wrote: post #370
KingMob wrote: post #247

Earlier quoted context omitted.

I think the evergreen use case for interrupting a rebase is, your manager came over to ask if you can drop everything and look at this bug that $TOP_CLIENT is screaming about. Git worktrees suffice, but they're still heavier weight than `jj new whatever`.

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 conditions Git creates makes it feel chaotic and jumpy. It's like being terrified of multithreaded code if you're not using Rust or a purely functional language.

Re: Jujutsu for busy devs

#390

Post by steveklabnik »

1718627440 wrote: post #227
stouset wrote: post #146

Earlier quoted context omitted.

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's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i`…

I wonder when LLMs will start messing with VCS. That will be fun :-/

Most coding llms already know git, and can handle jj pretty well too.
Post reply on HN