I added support for the -m|--message flag to the jj workspace add command, so you can set a message for the new commit that jj creates associated with the workspace.

With the current release as of this writing, when you add a workspace in a jj repo, an empty commit with no description is created.

$ jj workspace add /tmp/example
Created workspace in "/tmp/example"
Working copy  (@) now at: xouyultn fbf52c12 (empty) (no description set)
Parent commit (@-)      : vvyvvnsr d55579fd Initial
Added 1 file, modified 0 files, removed 0 files

It's simple enough to add a message after the fact with jj describe. (You can do this without changing directories to the workspace by using the workspace's name suffixed with the @ symbol as the optional revset argument, eg., jj describe -r 'example@' -m "...".) But I'm using jj more and more in automation contexts where it's nice to be able to do as many atomic operations as possible to minimize race conditions (and jj has transaction semantics for many of its commands, I'm not an expert on it though) and fewer multi-step operations to keep things simple.

With the change at c64d42, you can create a new workspace with a commit message:

$ jj workspace add -m 'a new workspace' /tmp/example
Working copy  (@) now at: ontxouwv b6236a1e (empty) a new workspace
Parent commit (@-)      : vvyvvnsr d55579fd Initial
Added 1 file, modified 0 files, removed 0 files

This was my first contribution to the jj project and I felt it went well.

It was easy to get a local development environment set up, because jj has a Nix flake for this purpose. That alone made this so approachable. I'm not a Rust expert, and a complex Rust development environment can sometimes take the wind out of my sails. Lately, I do see more and more OSS projects maintaining a flake.nix. It's one of the key things I look for when making that not-always-rational decision of whether to try to contribute.

jj has a clear and thorough document for contributors to refer to. I understood what they were looking for in terms of the PR, the commit message, commit history hygiene, etc. After I pushed a change in response to some review comments, some automated tooling informed me my commit message didn't meet formatting specs, which clued me to the fact that they want a squashed commit in any case.

After I resolved the review feedback, my change was approved, and I could click the merge button in GitHub myself. I like when projects do this; it's a small thing, but it feels good to be the one to land the change.

However, the merge queue check failed. At first glance, it seemed like it was due to a transient error with the build environment on the GitHub side. So I requeued it, and it failed again. I'm embarrassed to say that I didn't look closely at the reason why either run had failed, but after some kind, clear, and direct feedback from the maintainer Martin, I quickly fixed up the problem (a failing snapshot test that I had missed when, I think, my change was parented to the trunk), and everything was green.

The use of snapshot testing is another nice aspect of the jj project: the Rust crate insta makes it easy to prevent regressions based on the textual output of programs, including the lifecycle part of managing snapshots when the thing they are testing inevitably change. All of which is a convenient way to test a CLI tool, especially with jj's templates that let you customize the output.

I was also added to the GitHub jj-vcs/contributors organization. This is just a really well-run FOSS project, kudos to the core maintainers.

Now that I've made this change, I'm motivated to contribute some more. I've got a list of small improvements that would make my daily work a bit better. I've been using jj heavily for a few years now. It's completely replaced Git for me. I'm relying on jj workspaces in parallel agent development scenarios; I've found they are a great fit for this task. I feel jj is a great fit with agentic development in general, as its design removes a lot of stumbling blocks for agents in common VCS tasks.