Code review for Jujutsu

Jujutsu (jj) is a modern, Git-compatible version control system designed to be both simple and powerful. It keeps the working copy as a real commit, makes rewriting history safe and routine, and lets you describe what to operate on using a concise revset language.

Review Board treats Jujutsu as a first-class client. You keep using jj the way you already do, and RBTools posts your changes for review against any Review Board-connected Git repository.

Why teams use Review Board with Jujutsu

• Native change IDs. Post changes by Jujutsu change ID, bookmark, or revset. No need to think in Git SHAs.
• Stacked changes that stay stacked. Review Board can review any commit or range of commits in the middle of a larger stack, which fits naturally with how jj users work.
• Edit in place, keep your history. Jujutsu's normal workflow is to edit existing changes instead of amending. RBTools matches updates to the right review request automatically, and Review Board keeps every revision so reviewers can diff between any two.
• Open issues, not just comments. Mark a comment as an issue and it has to be resolved before the change can land.
• Review more than just code. Review Requests can include images, mockups, PDFs, Office documents, and more alongside your source.
• Interdiffs show how changes evolve over time. Routine jj squash and jj rebase rearrangements don't drown reviewers in noise.
• Hosting-agnostic. Works against GitHub, GitLab, Bitbucket, self-hosted Git, and more. You don't need your team to switch hosts to adopt jj.
• Your code stays private. Review Board can self-host in your network, and your code is never used for AI training.

How the integration works

You add your repository to Review Board once (using its Git URL) and developers install RBTools locally alongside jj. From there, posting a change is one command:

$ rbt post
Validating commits...
Uploading commits...

Review request #2 posted.

https://reviewboard/r/2/
https://reviewboard/r/2/diff/

By default, rbt post uses your nearest tracking bookmark as the base and includes everything up through @. You can also post a specific change, a bookmark, or any revset:

$ rbt post @                       # the working-copy change
$ rbt post <change-id>             # a specific change by ID
$ rbt post my-feature              # a bookmark
$ rbt post 'release-2.0..@'        # a revset (everything since release-2.0)

Made some edits in response to feedback? Just edit the change in place and run rbt post -u. RBTools matches it back to the original review request by summary and description, so updates land on the existing review thread with full discussion history intact:

$ rbt post -u
Validating commits...
Uploading commits...

Review request #2 posted.

https://reviewboard/r/2/
https://reviewboard/r/2/diff/

When the change is approved, rbt land merges it into your target branch (optionally squashing for a clean linear history) and can push upstream in the same step.

Configuration

A few settings in .reviewboardrc are worth knowing about:

• TRACKING_BRANCH = 'main@origin' — override the bookmark RBTools uses as the base for diffs.
• JJ_COMMITS_USE_GIT_SHA = True — identify commits by Git SHA instead of Jujutsu change ID, useful for shared repos where collaborators are on Git.
• LAND_DEST_BRANCH = 'main' and LAND_SQUASH = True — defaults for rbt land.
• TREES — per-user overrides, so you can use jj locally even when the team's .reviewboardrc is set up for Git.

See the Jujutsu workflow guide for the full reference.

Requirements

• Review Board or an RBCommons account.
• RBTools 6.0 or newer.

Jujutsu is still evolving quickly. We track upstream changes, but if a new jj release breaks something, please let us know.

Set up in 4 steps

1. Install Review Board or start an RBCommons trial
2. Add your Git repository to Review Board
3. Install RBTools on each developer's machine, alongside jj
4. Post your first change for review

FAQ

Do I need a special server-side repository type for Jujutsu?
No. Review Board talks to the underlying Git repository. Configure it the same way you'd configure any Git repo (GitHub, GitLab, Bitbucket, self-hosted, etc.).

Does this work with jj's native (non-Git) backend?
Not yet. The integration uses jj's Git colocation, so your repository needs to be backed by Git. Native-backend support is on our radar as the backend stabilizes upstream.

Can my team use Jujutsu and Git in the same repository at the same time?
Yes. That's a normal jj setup. Use TREES in .reviewboardrc to keep your local jj-specific overrides out of the shared team config.