About two weeks ago I tried out jj. It was clunky, I couldn’t figure out many things, and I ended up using my old git workflow. I did keep trying, though, and now today I’m fully using jj for every project I work on.
I’m a simple person and I like simple things, which is why I stick to a simple split style of using jj.
At a high level, it goes like this:
- (Sometimes) I’ll note the direction I’m heading
- I’ll write some new code and get distracted by old code I wrote
- I’ll get to a point where I finish an idea, and want to isolate it in my version control from the rest of the stuff I’ve done since my last checkpoint.
This is accomplished by starting new ideas like this:
jj new -m "@h the $thing is broken because of $reason"
I’ll then write a bunch of code, usually in more files than I originally intended to modify.
Once I get myself to a point where I want to create a checkpoint in my work, I’ll invoke my favorite command, jj split -i.
This brings up an interactive file explorer where I can “split” out one or more files from the current working tree, group them up into their own brand-new commit, and turn that new commit into the parent of my working tree.
I use @h at the beginning of any commit messages to let Future Me know that this was work done toward hypothesis testing. Often times it becomes work that I want to keep, but every once in a while it’s useful to be able to look back on some changes and feel confident in abandoning them–made all the more easier because they all start with the same two characters.
If you have a subset of files in your working copy you would like to pull out into a separate commit, you can use jj split -i to interactively select which files to do that with.
Let’s say you run jj st and see some files you’d like to pull out. For example, you’re working on Feature A but at some point you did some work for Feature N.
Whatever files associated with Feature N can be pulled out of the working copy and added to a new commit by using the split command.
I like to use jj split -i (the -i means interactive) to use the interactive file selector. This lets me select which files I want to “pull out” of the working copy.
So I’ll run jj split i, select the files that don’t belong in the current working copy, and then hit c (or click the File->Confirm TUI menu options). This prompts the commit message editor to pop up. You’ll see the description of the current working copy pre-populated. I will delete that, and replace it with a message the describes the work for Feature N that I am picking out of the working copy.
When you save that message, you’ll then have an opportunity to edit the current working copy message. I simply close the editor, which sets up my repo exactly how I want it: the files that should belong to Feature N have been pulled out of the working copy and added to a new commit that is now the parent commit of the working copy.