jj-run

run a command across a set of Jujutsu revisions

TLDR

Run a command on the current working-copy revision

$ jj run -- [command]

Run a command across a revset

$ jj run -r [revset] -- [command]

Run a formatter on every commit in the stack from trunk to `@`

$ jj run -r 'trunk()..@' -- cargo fmt

Print the change ID of each selected revision (`JJCHANGEID` is set per checkout)

$ jj run -r [revset] -- sh -c 'echo $JJ_CHANGE_ID'

Run in parallel across several revisions

$ jj run -r [revset] -j [4] -- [command]

Run without rewriting any commits (tests, linters)

$ jj run --ignore-changes -r [revset] -- [command]

Keep descendants' content unchanged instead of rebasing their diffs

$ jj run --restore-descendants -r [revset] -- [command]

Run from each checkout's workspace root rather than the subdirectory you invoked from

$ jj run -r [revset] --root -- [command]

jj run [-r REVSETS] [-j JOBS] [--root] [--clean] [--restore-descendants] [--passthrough] [--ignore-changes] [--ignore-errors] [global-options] -- COMMAND [ARGS...]

DESCRIPTION

jj run checks out each selected revision into an isolated working copy, runs COMMAND, then amends that revision with the resulting tree. By default descendants are rebased onto the amended revisions so the produced diff propagates. Use --restore-descendants to keep descendant content as-is, or --ignore-changes to execute without rewriting any commits.Each invocation sets:- JJ_CHANGE_ID — change id of the revision being processed- JJ_COMMIT_ID — commit id of that revision- JJ_WORKSPACE_ROOT — path of the isolated working copyTypical uses are formatters (`cargo fmt`, `prettier`), linters, test suites, and scripted edits (`sed`) across a stack. For per-file stdin/stdout formatters configured under `fix.tools`, jj fix is the dedicated command.

PARAMETERS

COMMAND [ARGS...]

Command to run in each selected revision. Use -- before the command so flags such as `-r` on the child command are not eaten by jj.

-r, --revision REVSETS

Revisions to operate on. Defaults to the working-copy commit `@`.

-j, --jobs JOBS

How many processes to run in parallel. Overrides `run.jobs`. Defaults to 1 if neither is set.

--root

Run the command from the working-copy root of each commit instead of the subdirectory jj run was invoked from.

--clean

Delete each isolated working copy before running the command. By default working copies are reused so build artifacts survive between invocations.

--restore-descendants

After amending, rebase descendants while preserving their content (not their diff).

--passthrough

Connect the command's stdout and stderr to the terminal instead of capturing them (progress bars, color). Stdin is not inherited. Forces a single job so output cannot interleave.

--ignore-changes

Check out each revision and run the command, but discard working-copy changes. Useful for tests and linters. Also allows running on immutable commits without --ignore-immutable.

--ignore-errors

Continue with remaining revisions when a command fails. Failed checkouts are not saved; successful ones still apply atomically at the end. A failed child does not change the exit code of jj run.

CONFIGURATION

Parallelism defaults:

$ [run]
jobs = 1

-j on the command line overrides `run.jobs`.

INSTALL

sudo pacman -S jujutsu

sudo apk add jujutsu

sudo zypper install jujutsu

brew install jujutsu

nix profile install nixpkgs#jujutsu

CAVEATS

Subcommand of jj. Mutating runs refuse immutable commits unless --ignore-immutable or --ignore-changes is set. --passthrough cannot be combined with more than one job. Without --, child flags that look like jj options are parsed by jj run. Isolated working copies are not the user's workspace; tools that assume a single checkout or write outside the tree will misbehave.

RESOURCES

Source code · Homepage · Documentation