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

Switch to Jujutsu Already: A Tutorial

stavros.io

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#91

Post by shaftway »

joshheyse wrote: post #80

In the age of Claude Code and other MCPs, the last thing I want is my commit history to be mutable. I've added instructions to Claude which make a commit before each modification with a summary of the conversation that caused the change. Once I'm happy with the work, I squash the commits and push up. (Which I believe is more or less equivalent to the jj workflow.)

This flow can work with jj also. It would probably be exactly the same. You'd do `jj new` and have Claude set the description and make its changes. When you're ready for the next round, you'd repeat and do `jj new` again for the next revision.

I think jj's mutable revisions are best thought of as automation around `git commit --amend && rebase_everything_after_this_commit`. If you're not using that kind of flow with Claude, you wouldn't use that kind of flow with jj either.

Re: Switch to Jujutsu Already: A Tutorial

#92

Post by sfink »

karmakaze wrote: post #81

Anyone using `jj`, how well does it scale? I routinely use .git folders that are 11GB (+4GB checked out files) and 10k+ branches without issue.

My data point is the Mozilla monorepo. My .git directory is 5.5GB, so half of what you're talking about. jj speed has not been a problem at all. Some thing are sped up a bit by enabling watchman, but I didn't bother for the first 4 months or so that I used it because the speed was already fine and I didn't want to add another point of failure. (And in fact, when I first enabled it, it slowed things down because the checkout is too big and hit inotify limits.)

I don't have very many branches, though. 13 branches, 6838 tags.

Some caveats: jj's version of `blame` (jj file annotate) is painfully slow and I usually run `git blame` instead. (Which is a general thing: if anything is missing or slow, you can always just do it with git.) jj's rebase is insanely fast -- especially if you add in the time to manually resolve conflicts, since a good chunk of the time I don't have to spend any time at all since the conflicts are only in experimental twigs that I may never need to go back to (and if I do, it's fine to wait until I need it).

Re: Switch to Jujutsu Already: A Tutorial

#93

Post by 1718627440 »

shaftway wrote: post #90
1718627440 wrote: post #89

Earlier quoted context omitted.

> Now my PRs are split into human-sized commits that each contain a set of changes that make sense together, and I keep moving changes around during development to keep the history tidy, until it's time to send the pull request. If a commit introduces a typo, the typo fix should go into that commit so the typo never happened in the first place and you don't get reviews like "please fix this" and then "oh wait I see y…

> > You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it. > That sounds the same in Git? I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago. In JJ…

You have the same two options in Git:

    vim file/with/typo.txt
    git add file/with/typo.txt
    git commit --fixup=abcd1234
    git rebase --autosquash -i
For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended.

The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234 was the last time you modified these lines.

The second approach is this:

    git rebase -i abcd1234~
    # do 's/pick abcd1234/edit abcd1234/' in your editor
    vim file/with/typo.txt
    git rebase --continue

Re: Switch to Jujutsu Already: A Tutorial

#94

Post by sfink »

1718627440 wrote: post #76

When checking out means to just "reopen" an older commit, how do you checkout single files in JJ?

Depends on what you mean. "Checking out" is ambiguous, and in fact isn't jj terminology. As git terminology, it could mean switching branches or showing file contents or going to a detached HEAD or resetting file contents.

If you want the contents of the file at some old commit 0a123, `jj file show -r 0a123 `. If you want to overwrite the current version of a file with the version from 0a123, `jj restore --from 0a123 `.

How do you "checkout single files" in git? What does that mean?

Re: Switch to Jujutsu Already: A Tutorial

#95

Post by 1718627440 »

sfink wrote: post #94
1718627440 wrote: post #76

When checking out means to just "reopen" an older commit, how do you checkout single files in JJ?

Depends on what you mean. "Checking out" is ambiguous, and in fact isn't jj terminology. As git terminology, it could mean switching branches or showing file contents or going to a detached HEAD or resetting file contents. If you want the contents of the file at some old commit 0a123, `jj file show -r 0a123 `. If you want to overwrite the current version of a file with the version from 0a123, `jj restore --from 0a123…

> How do you "checkout single files" in git? What does that mean?

    git checkout 0a123 --
So the answer is jj restore. Thanks.

Checkout means that the version of some files at some commit is "checked out" in the worktree. So all these things are mostly the same in Git terms. The arbitrary split into switch and restore is confusing to me.

Re: Switch to Jujutsu Already: A Tutorial

#96

Post by 1718627440 »

stavros wrote: post #5
itchynosedev wrote: post #4

I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git. In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.

Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?

I also use them, because I don't know a better alternative. I want it the subproject's version to be defined in a parent's commit and also modify the subproject. Changes to the subproject should stay in the commit history of the subproject Is there a better way?

Re: Switch to Jujutsu Already: A Tutorial

#97

Post by 1718627440 »

simgt wrote: post #19
roxolotl wrote: post #6

> Jujutsu, in contrast, is more like playing with Play-Doh. You take a lump, cut it into two, shape one piece into something, give it a name, change your mind, give it another name, take a bit of the second piece and stick it on the first piece, and generally go back and forth all around your play area, making changes. I love this description and it describes how I work with git. When I’m doing things locally I’m con…

That's how I feel like working with git locally using a combination of basic commands and gitup ( https://gitup.co/ ), that may be why I couldn't really get the selling point of jj when I tried it a couple weeks ago. The only part that piqued my interest is merges being always successful and conflicts just sitting in the tree, waiting patiently to be resolved... It's the next logical step after being able to commit w…

> gitup (https://gitup.co/)

That looks actually nice, but it seams to require macOS.

Re: Switch to Jujutsu Already: A Tutorial

#98

Post by tcoff91 »

umvi wrote: post #88
tcoff91 wrote: post #49

Earlier quoted context omitted.

I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools. Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python. https://ofcr.se/jujutsu-merge-workflow/

Well then articles should focus on that if they want to convince people who use git as a daily driver. Currently the impression I get from jj is that it's "git for people who have a hard time understanding/using git", therefore since I don't have a hard time understanding/using git, jj is not for me. Maybe more articles showing galaxy brain SCM workflows that are difficult under git but possible under jj and are kill…

I wholeheartedly agree with you. What makes jj a killer app to me is that it allows me to work with source control in a whole new way that just feels so much more powerful to me. I haven't felt like this since I first discovered git after dealing with the pain of subversion.

Re: Switch to Jujutsu Already: A Tutorial

#99

Post by SAI_Peregrinus »

stavros wrote: post #15
wakamoleguy wrote: post #14

Earlier quoted context omitted.

Maybe it’s based on whether the GitHub merge is a squash, rebase, or plain merge? Or do folks usually manually perform the merge with jj?

It shouldn't matter, under the hood the tree is the same for both. I don't know why jj would complain but git wouldn't, hm.

I wonder if they've got files tracked by git-lfs. `jj` doesn't handle those yet.

Re: Switch to Jujutsu Already: A Tutorial

#100

Post by baq »

karmakaze wrote: post #79
stavros wrote: post #72

Earlier quoted context omitted.

Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point .

Fair enough. I'll reconsider if my git workflow is impacted to a point where it shows up to be non-negligible under Amdahl's Law. Edit: read more of the post and I still don't see the big deal. It's like rebase/edit with a bit less typing.

‘A bit less typing’ is the point, it makes a painful workflow into a pleasurable one.
Post reply on HN