Jujutsu for Busy Devs

Re:Jujutsu for Busy Devs by Lyngbakr on Monday July 21, 2025 @09:05PM (#44642232)

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that change or something to prevent this. Perhaps it's just habit, but I feel more comfortable explicitly saying what I want to commit rather that defaulting to everything. Or have I totally misunderstood jj?

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by stouset on Monday July 21, 2025 @09:15PM (#44642278)

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 something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj but a bunch of annoying branch-switching and stashing in git.

You can also use a `git add`-style workflow. Create a new revision with `jj new`. Do it again. Make your changes, then `jj squash -i/--interactive` to select the bits you want to include. Keep making changes and squashing into the previous commit you’re building up until you’re happy. Conceptually just think of @ (the current revision) and @- (the previous revision) as the working copy and the staged copy, respectively.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by palata on Tuesday July 22, 2025 @03:54AM (#44644324)

I feel like I already lost more time reading this than jj would make me win if I switched :-).

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by stouset on Tuesday July 22, 2025 @12:47PM (#44649773)

In the first year of switching I easily saved more time and frustration than the sum total of all of my jj evangelism on HN.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by 0cf8612b2e1e on Monday July 21, 2025 @09:13PM (#44642273)

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development.

Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by oxidant on Monday July 21, 2025 @11:58PM (#44643103)

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by 0cf8612b2e1e on Tuesday July 22, 2025 @12:23AM (#44643221)

The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage.

I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by steveklabnik on Tuesday July 22, 2025 @12:41AM (#44643296)

Just to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream.

(though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by baq on Tuesday July 22, 2025 @03:39AM (#44644214)

There is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by andrewaylett on Tuesday July 22, 2025 @03:06PM (#44651621)

A tool like pre-commit really helps here: it'll run against the staged files, before committing. Your CI tool really ought to be testing the commit too, at which point having a clean commit locally isn't necessary for correctness, only for avoiding needing to re-do your work.

It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by sunshowers on Tuesday July 22, 2025 @03:04AM (#44643998)

I think most people would use a logging library (maybe at the "trace" level) at that point.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by arccy on Tuesday July 22, 2025 @06:37AM (#44645278)

you've obviously never encountered code which only works when println is added.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by oxidant on Tuesday July 22, 2025 @10:25PM (#44655182)

Schroedingers branching

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by rtpg on Monday July 21, 2025 @09:29PM (#44642351)

I usually work, then do `jj split` to review changes I want to make commits to. This generally makes the workflow look like `git add -p`.

A decent mental model is that the top-most commit isn't generally going to get pushed up anywhere. It's like your working copy but also you get stashing "for free" (change back to main to make a new commit? All the WIP stuff stays on that branch instead of being carried over to main!)

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by do_not_redeem on Monday July 21, 2025 @09:12PM (#44642264)

If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by 000ooo000 on Tuesday July 22, 2025 @02:13AM (#44643706)

FWIW, @ is a shortcut for HEAD in Git.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by Nzen on Tuesday July 22, 2025 @11:38AM (#44648516)

When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence.

[0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by ethan_smith on Monday July 21, 2025 @09:38PM (#44642402)

You can use `jj ignore` or add patterns to `.jjignore` for files you don't want tracked, or use `jj edit --no-snapshot` to prevent automatic tracking during specific edit sessions.

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by notmywalrus on Monday July 21, 2025 @10:16PM (#44642624)

...no? On all counts.

`jj ignore` is not a command. [1]

There is no such thing as `.jjignore` files [2], [3].

`--no-snapshot` is not a flag, neither on `jj edit` nor in general. Additionally, it doesn't make sense conceptually --- `jj edit` changes the working copy, which will then propagate changes to the selected commit every time you edit a file.

If you want to check out an old commit without amending it, you `jj new` on top of it. If you end up making changes that you don't care about, you can `jj abandon` them.

[1]: https://jj-vcs.github.io/jj/latest/cli-reference/

[2]: https://github.com/jj-vcs/jj/issues/3525

[3]: https://jj-vcs.github.io/jj/latest/working-copy/#ignored-fil...

[ Parent | on HN ]

Re:Jujutsu for Busy Devs by simonmic on Tuesday July 22, 2025 @06:30AM (#44645240)

jj's auto staging isn't always desirable. I feel jj docs and evangelists should make clearer that it's easy to turn off by default, by adding this to ~/.jjconfig:

    [snapshot]
    auto-track = "none()"

[ Parent | on HN ]