Hacker News Reader

Comment by Lyngbakr | Hacker News Reader

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?

View on HN

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.

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

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.

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!)

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()"

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

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

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.

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

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.

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.

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

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

Schroedingers branching

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

FWIW, @ is a shortcut for HEAD in Git.

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

Reply on news.ycombinator.com