---
source: cli/tests/test_generate_md_cli_help.rs
description: "AUTO-GENERATED FILE, DO NOT EDIT. This cli reference is generated by a test as an `insta` snapshot. MkDocs includes this snapshot from docs/cli-reference.md."
---
<!-- BEGIN MARKDOWN-->

# Command-Line Help for `jj`

This document contains the help content for the `jj` command-line program.

**Command Overview:**

* [`jj`↴](#jj)
* [`jj abandon`↴](#jj-abandon)
* [`jj backout`↴](#jj-backout)
* [`jj branch`↴](#jj-branch)
* [`jj branch create`↴](#jj-branch-create)
* [`jj branch delete`↴](#jj-branch-delete)
* [`jj branch forget`↴](#jj-branch-forget)
* [`jj branch list`↴](#jj-branch-list)
* [`jj branch move`↴](#jj-branch-move)
* [`jj branch rename`↴](#jj-branch-rename)
* [`jj branch set`↴](#jj-branch-set)
* [`jj branch track`↴](#jj-branch-track)
* [`jj branch untrack`↴](#jj-branch-untrack)
* [`jj commit`↴](#jj-commit)
* [`jj config`↴](#jj-config)
* [`jj config edit`↴](#jj-config-edit)
* [`jj config get`↴](#jj-config-get)
* [`jj config list`↴](#jj-config-list)
* [`jj config path`↴](#jj-config-path)
* [`jj config set`↴](#jj-config-set)
* [`jj describe`↴](#jj-describe)
* [`jj diff`↴](#jj-diff)
* [`jj diffedit`↴](#jj-diffedit)
* [`jj duplicate`↴](#jj-duplicate)
* [`jj edit`↴](#jj-edit)
* [`jj file`↴](#jj-file)
* [`jj file chmod`↴](#jj-file-chmod)
* [`jj file list`↴](#jj-file-list)
* [`jj file show`↴](#jj-file-show)
* [`jj fix`↴](#jj-fix)
* [`jj git`↴](#jj-git)
* [`jj git clone`↴](#jj-git-clone)
* [`jj git export`↴](#jj-git-export)
* [`jj git fetch`↴](#jj-git-fetch)
* [`jj git import`↴](#jj-git-import)
* [`jj git init`↴](#jj-git-init)
* [`jj git push`↴](#jj-git-push)
* [`jj git remote`↴](#jj-git-remote)
* [`jj git remote add`↴](#jj-git-remote-add)
* [`jj git remote list`↴](#jj-git-remote-list)
* [`jj git remote remove`↴](#jj-git-remote-remove)
* [`jj git remote rename`↴](#jj-git-remote-rename)
* [`jj git remote set-url`↴](#jj-git-remote-set-url)
* [`jj init`↴](#jj-init)
* [`jj interdiff`↴](#jj-interdiff)
* [`jj log`↴](#jj-log)
* [`jj new`↴](#jj-new)
* [`jj next`↴](#jj-next)
* [`jj obslog`↴](#jj-obslog)
* [`jj operation`↴](#jj-operation)
* [`jj operation abandon`↴](#jj-operation-abandon)
* [`jj operation log`↴](#jj-operation-log)
* [`jj operation restore`↴](#jj-operation-restore)
* [`jj operation undo`↴](#jj-operation-undo)
* [`jj parallelize`↴](#jj-parallelize)
* [`jj prev`↴](#jj-prev)
* [`jj rebase`↴](#jj-rebase)
* [`jj resolve`↴](#jj-resolve)
* [`jj restore`↴](#jj-restore)
* [`jj root`↴](#jj-root)
* [`jj show`↴](#jj-show)
* [`jj sparse`↴](#jj-sparse)
* [`jj sparse edit`↴](#jj-sparse-edit)
* [`jj sparse list`↴](#jj-sparse-list)
* [`jj sparse reset`↴](#jj-sparse-reset)
* [`jj sparse set`↴](#jj-sparse-set)
* [`jj split`↴](#jj-split)
* [`jj squash`↴](#jj-squash)
* [`jj status`↴](#jj-status)
* [`jj tag`↴](#jj-tag)
* [`jj tag list`↴](#jj-tag-list)
* [`jj util`↴](#jj-util)
* [`jj util completion`↴](#jj-util-completion)
* [`jj util gc`↴](#jj-util-gc)
* [`jj util mangen`↴](#jj-util-mangen)
* [`jj util markdown-help`↴](#jj-util-markdown-help)
* [`jj util config-schema`↴](#jj-util-config-schema)
* [`jj undo`↴](#jj-undo)
* [`jj unsquash`↴](#jj-unsquash)
* [`jj untrack`↴](#jj-untrack)
* [`jj version`↴](#jj-version)
* [`jj workspace`↴](#jj-workspace)
* [`jj workspace add`↴](#jj-workspace-add)
* [`jj workspace forget`↴](#jj-workspace-forget)
* [`jj workspace list`↴](#jj-workspace-list)
* [`jj workspace root`↴](#jj-workspace-root)
* [`jj workspace update-stale`↴](#jj-workspace-update-stale)

## `jj`

Jujutsu (An experimental VCS)

To get started, see the tutorial at https://github.com/martinvonz/jj/blob/main/docs/tutorial.md.

**Usage:** `jj [OPTIONS] [COMMAND]`

###### **Subcommands:**

* `abandon` — Abandon a revision
* `backout` — Apply the reverse of a revision on top of another revision
* `branch` — Manage branches
* `commit` — Update the description and create a new change on top
* `config` — Manage config options
* `describe` — Update the change description or other metadata
* `diff` — Compare file contents between two revisions
* `diffedit` — Touch up the content changes in a revision with a diff editor
* `duplicate` — Create a new change with the same content as an existing one
* `edit` — Sets the specified revision as the working-copy revision
* `file` — File operations
* `fix` — Update files with formatting fixes or other changes
* `git` — Commands for working with Git remotes and the underlying Git repo
* `init` — Create a new repo in the given directory
* `interdiff` — Compare the changes of two commits
* `log` — Show revision history
* `new` — Create a new, empty change and (by default) edit it in the working copy
* `next` — Move the working-copy commit to the child revision
* `obslog` — Show how a change has evolved over time
* `operation` — Commands for working with the operation log
* `parallelize` — Parallelize revisions by making them siblings
* `prev` — Change the working copy revision relative to the parent revision
* `rebase` — Move revisions to different parent(s)
* `resolve` — Resolve a conflicted file with an external merge tool
* `restore` — Restore paths from another revision
* `root` — Show the current workspace root directory
* `show` — Show commit description and changes in a revision
* `sparse` — Manage which paths from the working-copy commit are present in the working copy
* `split` — Split a revision in two
* `squash` — Move changes from a revision into another revision
* `status` — Show high-level repo status
* `tag` — Manage tags
* `util` — Infrequently used commands such as for generating shell completions
* `undo` — Undo an operation (shortcut for `jj op undo`)
* `unsquash` — Move changes from a revision's parent into the revision
* `untrack` — Stop tracking specified paths in the working copy
* `version` — Display version information
* `workspace` — Commands for working with workspaces

###### **Options:**

* `-R`, `--repository <REPOSITORY>` — Path to repository to operate on

   By default, Jujutsu searches for the closest .jj/ directory in an ancestor of the current working directory.
* `--ignore-working-copy` — Don't snapshot the working copy, and don't update it

   By default, Jujutsu snapshots the working copy at the beginning of every command. The working copy is also updated at the end of the command, if the command modified the working-copy commit (`@`). If you want to avoid snapshotting the working copy and instead see a possibly stale working copy commit, you can use `--ignore-working-copy`. This may be useful e.g. in a command prompt, especially if you have another process that commits the working copy.

   Loading the repository at a specific operation with `--at-operation` implies `--ignore-working-copy`.
* `--ignore-immutable` — Allow rewriting immutable commits

   By default, Jujutsu prevents rewriting commits in the configured set of immutable commits. This option disables that check and lets you rewrite any commit but the root commit.

   This option only affects the check. It does not affect the `immutable_heads()` revset or the `immutable` template keyword.
* `--at-operation <AT_OPERATION>` — Operation to load the repo at

   Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation. You can use `--at-op=<operation ID>` to see what the repo looked like at an earlier operation. For example `jj --at-op=<operation ID> st` will show you what `jj st` would have shown you when the given operation had just finished.

   Use `jj op log` to find the operation ID you want. Any unambiguous prefix of the operation ID is enough.

   When loading the repo at an earlier operation, the working copy will be ignored, as if `--ignore-working-copy` had been specified.

   It is possible to run mutating commands when loading the repo at an earlier operation. Doing that is equivalent to having run concurrent commands starting at the earlier operation. There's rarely a reason to do that, but it is possible.

  Default value: `@`
* `--debug` — Enable debug logging
* `--color <WHEN>` — When to colorize output (always, never, debug, auto)
* `--quiet` — Silence non-primary command output

   For example, `jj file list ` will still list files, but it won't tell you if the working copy was snapshotted or if descendants were rebased.

   Warnings and errors will still be printed.
* `--no-pager` — Disable the pager
* `--config-toml <TOML>` — Additional configuration options (can be repeated)



## `jj abandon`

Abandon a revision

Abandon a revision, rebasing descendants onto its parent(s). The behavior is similar to `jj restore --changes-in`; the difference is that `jj abandon` gives you a new change, while `jj restore` updates the existing change.

If a working-copy commit gets abandoned, it will be given a new, empty commit. This is true in general; it is not specific to this command.

**Usage:** `jj abandon [OPTIONS] [REVISIONS]...`

###### **Arguments:**

* `<REVISIONS>` — The revision(s) to abandon

  Default value: `@`

###### **Options:**

* `-s`, `--summary` — Do not print every abandoned commit on a separate line



## `jj backout`

Apply the reverse of a revision on top of another revision

**Usage:** `jj backout [OPTIONS]`

###### **Options:**

* `-r`, `--revisions <REVISIONS>` — The revision(s) to apply the reverse of

  Default value: `@`
* `-d`, `--destination <DESTINATION>` — The revision to apply the reverse changes on top of

  Default value: `@`



## `jj branch`

Manage branches

For information about branches, see https://github.com/martinvonz/jj/blob/main/docs/branches.md.

**Usage:** `jj branch <COMMAND>`

###### **Subcommands:**

* `create` — Create a new branch
* `delete` — Delete an existing branch and propagate the deletion to remotes on the next push
* `forget` — Forget everything about a branch, including its local and remote targets
* `list` — List branches and their targets
* `move` — Move existing branches to target revision
* `rename` — Rename `old` branch name to `new` branch name
* `set` — Create or update a branch to point to a certain commit
* `track` — Start tracking given remote branches
* `untrack` — Stop tracking given remote branches



## `jj branch create`

Create a new branch

**Usage:** `jj branch create [OPTIONS] <NAMES>...`

###### **Arguments:**

* `<NAMES>` — The branches to create

###### **Options:**

* `-r`, `--revision <REVISION>` — The branch's target revision



## `jj branch delete`

Delete an existing branch and propagate the deletion to remotes on the next push

**Usage:** `jj branch delete <NAMES>...`

###### **Arguments:**

* `<NAMES>` — The branches to delete

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.



## `jj branch forget`

Forget everything about a branch, including its local and remote targets

A forgotten branch will not impact remotes on future pushes. It will be recreated on future pulls if it still exists in the remote.

**Usage:** `jj branch forget <NAMES>...`

###### **Arguments:**

* `<NAMES>` — The branches to forget

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.



## `jj branch list`

List branches and their targets

By default, a tracking remote branch will be included only if its target is different from the local target. A non-tracking remote branch won't be listed. For a conflicted branch (both local and remote), old target revisions are preceded by a "-" and new target revisions are preceded by a "+".

For information about branches, see https://github.com/martinvonz/jj/blob/main/docs/branches.md.

**Usage:** `jj branch list [OPTIONS] [NAMES]...`

###### **Arguments:**

* `<NAMES>` — Show branches whose local name matches

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.

###### **Options:**

* `-a`, `--all-remotes` — Show all tracking and non-tracking remote branches including the ones whose targets are synchronized with the local branches
* `-t`, `--tracked` — Show remote tracked branches only. Omits local Git-tracking branches by default
* `-c`, `--conflicted` — Show conflicted branches only
* `-r`, `--revisions <REVISIONS>` — Show branches whose local targets are in the given revisions

   Note that `-r deleted_branch` will not work since `deleted_branch` wouldn't have a local target.
* `-T`, `--template <TEMPLATE>` — Render each branch using the given template

   All 0-argument methods of the `RefName` type are available as keywords.

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md



## `jj branch move`

Move existing branches to target revision

If branch names are given, the specified branches will be updated to point to the target revision.

If `--from` options are given, branches currently pointing to the specified revisions will be updated. The branches can also be filtered by names.

Example: pull up the nearest branches to the working-copy parent

$ jj branch move --from 'heads(::@- & branches())' --to @-

**Usage:** `jj branch move [OPTIONS] <--from <REVISIONS>|NAMES>`

###### **Arguments:**

* `<NAMES>` — Move branches matching the given name patterns

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.

###### **Options:**

* `--from <REVISIONS>` — Move branches from the given revisions
* `--to <REVISION>` — Move branches to this revision

  Default value: `@`
* `-B`, `--allow-backwards` — Allow moving branches backwards or sideways



## `jj branch rename`

Rename `old` branch name to `new` branch name

The new branch name points at the same commit as the old branch name.

**Usage:** `jj branch rename <OLD> <NEW>`

###### **Arguments:**

* `<OLD>` — The old name of the branch
* `<NEW>` — The new name of the branch



## `jj branch set`

Create or update a branch to point to a certain commit

**Usage:** `jj branch set [OPTIONS] <NAMES>...`

###### **Arguments:**

* `<NAMES>` — The branches to update

###### **Options:**

* `-r`, `--revision <REVISION>` — The branch's target revision
* `-B`, `--allow-backwards` — Allow moving the branch backwards or sideways



## `jj branch track`

Start tracking given remote branches

A tracking remote branch will be imported as a local branch of the same name. Changes to it will propagate to the existing local branch on future pulls.

**Usage:** `jj branch track <BRANCH@REMOTE>...`

###### **Arguments:**

* `<BRANCH@REMOTE>` — Remote branches to track

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.

   Examples: branch@remote, glob:main@*, glob:jjfan-*@upstream



## `jj branch untrack`

Stop tracking given remote branches

A non-tracking remote branch is just a pointer to the last-fetched remote branch. It won't be imported as a local branch on future pulls.

**Usage:** `jj branch untrack <BRANCH@REMOTE>...`

###### **Arguments:**

* `<BRANCH@REMOTE>` — Remote branches to untrack

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.

   Examples: branch@remote, glob:main@*, glob:jjfan-*@upstream



## `jj commit`

Update the description and create a new change on top

**Usage:** `jj commit [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Put these paths in the first commit

###### **Options:**

* `-i`, `--interactive` — Interactively choose which changes to include in the first commit
* `--tool <NAME>` — Specify diff editor to be used (implies --interactive)
* `-m`, `--message <MESSAGE>` — The change description to use (don't open editor)
* `--reset-author` — Reset the author to the configured user

   This resets the author name, email, and timestamp.

   You can use it in combination with the JJ_USER and JJ_EMAIL environment variables to set a different author:

   $ JJ_USER='Foo Bar' JJ_EMAIL=foo@bar.com jj commit --reset-author



## `jj config`

Manage config options

Operates on jj configuration, which comes from the config file and environment variables.

For file locations, supported config options, and other details about jj config, see https://github.com/martinvonz/jj/blob/main/docs/config.md.

**Usage:** `jj config <COMMAND>`

###### **Subcommands:**

* `edit` — Start an editor on a jj config file
* `get` — Get the value of a given config option.
* `list` — List variables set in config file, along with their values
* `path` — Print the path to the config file
* `set` — Update config file to set the given option to a given value



## `jj config edit`

Start an editor on a jj config file.

Creates the file if it doesn't already exist regardless of what the editor does.

**Usage:** `jj config edit <--user|--repo>`

###### **Options:**

* `--user` — Target the user-level config
* `--repo` — Target the repo-level config



## `jj config get`

Get the value of a given config option.

Unlike `jj config list`, the result of `jj config get` is printed without
extra formatting and therefore is usable in scripting. For example:

$ jj config list user.name
user.name="Martin von Zweigbergk"
$ jj config get user.name
Martin von Zweigbergk

**Usage:** `jj config get <NAME>`

###### **Arguments:**

* `<NAME>`



## `jj config list`

List variables set in config file, along with their values

**Usage:** `jj config list [OPTIONS] [NAME]`

###### **Arguments:**

* `<NAME>` — An optional name of a specific config option to look up

###### **Options:**

* `--include-defaults` — Whether to explicitly include built-in default values in the list
* `--include-overridden` — Allow printing overridden values
* `--user` — Target the user-level config
* `--repo` — Target the repo-level config
* `-T`, `--template <TEMPLATE>` — Render each variable using the given template

   The following keywords are defined:

   * `name: String`: Config name.
   * `value: String`: Serialized value in TOML syntax.
   * `overridden: Boolean`: True if the value is shadowed by other.

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md



## `jj config path`

Print the path to the config file

A config file at that path may or may not exist.

See `jj config edit` if you'd like to immediately edit the file.

**Usage:** `jj config path <--user|--repo>`

###### **Options:**

* `--user` — Target the user-level config
* `--repo` — Target the repo-level config



## `jj config set`

Update config file to set the given option to a given value

**Usage:** `jj config set <--user|--repo> <NAME> <VALUE>`

###### **Arguments:**

* `<NAME>`
* `<VALUE>`

###### **Options:**

* `--user` — Target the user-level config
* `--repo` — Target the repo-level config



## `jj describe`

Update the change description or other metadata

Starts an editor to let you edit the description of a change. The editor will be $EDITOR, or `pico` if that's not defined (`Notepad` on Windows).

**Usage:** `jj describe [OPTIONS] [REVISION]`

###### **Arguments:**

* `<REVISION>` — The revision whose description to edit

  Default value: `@`

###### **Options:**

* `-m`, `--message <MESSAGE>` — The change description to use (don't open editor)
* `--stdin` — Read the change description from stdin
* `--no-edit` — Don't open an editor

   This is mainly useful in combination with e.g. `--reset-author`.
* `--reset-author` — Reset the author to the configured user

   This resets the author name, email, and timestamp.

   You can use it in combination with the JJ_USER and JJ_EMAIL environment variables to set a different author:

   $ JJ_USER='Foo Bar' JJ_EMAIL=foo@bar.com jj describe --reset-author



## `jj diff`

Compare file contents between two revisions

With the `-r` option, which is the default, shows the changes compared to the parent revision. If there are several parent revisions (i.e., the given revision is a merge), then they will be merged and the changes from the result to the given revision will be shown.

With the `--from` and/or `--to` options, shows the difference from/to the given revisions. If either is left out, it defaults to the working-copy commit. For example, `jj diff --from main` shows the changes from "main" (perhaps a branch name) to the working-copy commit.

**Usage:** `jj diff [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Restrict the diff to these paths

###### **Options:**

* `-r`, `--revision <REVISION>` — Show changes in this revision, compared to its parent(s)

   If the revision is a merge commit, this shows changes *from* the automatic merge of the contents of all of its parents *to* the contents of the revision itself.
* `--from <FROM>` — Show changes from this revision
* `--to <TO>` — Show changes to this revision
* `-s`, `--summary` — For each path, show only whether it was modified, added, or deleted
* `--stat` — Show a histogram of the changes
* `--types` — For each path, show only its type before and after

   The diff is shown as two letters. The first letter indicates the type before and the second letter indicates the type after. '-' indicates that the path was not present, 'F' represents a regular file, `L' represents a symlink, 'C' represents a conflict, and 'G' represents a Git submodule.
* `--name-only` — For each path, show only its path

   Typically useful for shell commands like: `jj diff -r @- --name_only | xargs perl -pi -e's/OLD/NEW/g`
* `--git` — Show a Git-format diff
* `--color-words` — Show a word-level diff with changes indicated only by color
* `--tool <TOOL>` — Generate diff by external command
* `--context <CONTEXT>` — Number of lines of context to show



## `jj diffedit`

Touch up the content changes in a revision with a diff editor

With the `-r` option, which is the default, starts a [diff editor] on the changes in the revision.

With the `--from` and/or `--to` options, starts a [diff editor] comparing the "from" revision to the "to" revision.

[diff editor]: https://martinvonz.github.io/jj/latest/config/#editing-diffs

Edit the right side of the diff until it looks the way you want. Once you close the editor, the revision specified with `-r` or `--to` will be updated. Descendants will be rebased on top as usual, which may result in conflicts.

See `jj restore` if you want to move entire files from one revision to another. See `jj squash -i` or `jj unsquash -i` if you instead want to move changes into or out of the parent revision.

**Usage:** `jj diffedit [OPTIONS]`

###### **Options:**

* `-r`, `--revision <REVISION>` — The revision to touch up. Defaults to @ if neither --to nor --from are specified
* `--from <FROM>` — Show changes from this revision. Defaults to @ if --to is specified
* `--to <TO>` — Edit changes in this revision. Defaults to @ if --from is specified
* `--tool <NAME>` — Specify diff editor to be used



## `jj duplicate`

Create a new change with the same content as an existing one

**Usage:** `jj duplicate [REVISIONS]...`

###### **Arguments:**

* `<REVISIONS>` — The revision(s) to duplicate

  Default value: `@`



## `jj edit`

Sets the specified revision as the working-copy revision

Note: it is generally recommended to instead use `jj new` and `jj squash`.

For more information, see https://martinvonz.github.io/jj/latest/FAQ#how-do-i-resume-working-on-an-existing-change

**Usage:** `jj edit <REVISION>`

###### **Arguments:**

* `<REVISION>` — The commit to edit



## `jj file`

File operations

**Usage:** `jj file <COMMAND>`

###### **Subcommands:**

* `chmod` — Sets or removes the executable bit for paths in the repo
* `list` — List files in a revision
* `show` — Print contents of files in a revision



## `jj file chmod`

Sets or removes the executable bit for paths in the repo

Unlike the POSIX `chmod`, `jj file chmod` also works on Windows, on conflicted files, and on arbitrary revisions.

**Usage:** `jj file chmod [OPTIONS] <MODE> <PATHS>...`

###### **Arguments:**

* `<MODE>`

  Possible values:
  - `n`:
    Make a path non-executable (alias: normal)
  - `x`:
    Make a path executable (alias: executable)

* `<PATHS>` — Paths to change the executable bit for

###### **Options:**

* `-r`, `--revision <REVISION>` — The revision to update

  Default value: `@`



## `jj file list`

List files in a revision

**Usage:** `jj file list [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Only list files matching these prefixes (instead of all files)

###### **Options:**

* `-r`, `--revision <REVISION>` — The revision to list files in

  Default value: `@`



## `jj file show`

Print contents of files in a revision

If the given path is a directory, files in the directory will be visited recursively.

**Usage:** `jj file show [OPTIONS] <PATHS>...`

###### **Arguments:**

* `<PATHS>` — Paths to print

###### **Options:**

* `-r`, `--revision <REVISION>` — The revision to get the file contents from

  Default value: `@`



## `jj fix`

Update files with formatting fixes or other changes

The primary use case for this command is to apply the results of automatic
code formatting tools to revisions that may not be properly formatted yet.
It can also be used to modify files with other tools like `sed` or `sort`.

The changed files in the given revisions will be updated with any fixes
determined by passing their file content through the external tool.
Descendants will also be updated by passing their versions of the same files
through the same external tool, which will never result in new conflicts.
Files with existing conflicts will be updated on all sides of the conflict,
which can potentially increase or decrease the number of conflict markers.

The external tool must accept the current file content on standard input,
and return the updated file content on standard output. The output will not
be used unless the tool exits with a successful exit code. Output on
standard error will be passed through to the terminal.

The configuration schema is expected to change in the future. For now, it
defines a single command that will affect all changed files in the specified
revisions. For example, to format some Rust code changed in the working copy
revision, you could write this configuration:

[fix]
tool-command = ["rustfmt", "--emit", "stdout"]

And then run the command `jj fix -s @`.

**Usage:** `jj fix [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Fix only these paths

###### **Options:**

* `-s`, `--source <SOURCE>` — Fix files in the specified revision(s) and their descendants. If no revisions are specified, this defaults to the `revsets.fix` setting, or `reachable(@, mutable())` if it is not set



## `jj git`

Commands for working with Git remotes and the underlying Git repo

For a comparison with Git, including a table of commands, see https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md.

**Usage:** `jj git <COMMAND>`

###### **Subcommands:**

* `clone` — Create a new repo backed by a clone of a Git repo
* `export` — Update the underlying Git repo with changes made in the repo
* `fetch` — Fetch from a Git remote
* `import` — Update repo with changes made in the underlying Git repo
* `init` — Create a new Git backed repo
* `push` — Push to a Git remote
* `remote` — Manage Git remotes



## `jj git clone`

Create a new repo backed by a clone of a Git repo

The Git repo will be a bare git repo stored inside the `.jj/` directory.

**Usage:** `jj git clone [OPTIONS] <SOURCE> [DESTINATION]`

###### **Arguments:**

* `<SOURCE>` — URL or path of the Git repo to clone
* `<DESTINATION>` — Specifies the target directory for the Jujutsu repository clone. If not provided, defaults to a directory named after the last component of the source URL. The full directory path will be created if it doesn't exist

###### **Options:**

* `--colocate` — Whether or not to colocate the Jujutsu repo with the git repo



## `jj git export`

Update the underlying Git repo with changes made in the repo

**Usage:** `jj git export`



## `jj git fetch`

Fetch from a Git remote

If a working-copy commit gets abandoned, it will be given a new, empty commit. This is true in general; it is not specific to this command.

**Usage:** `jj git fetch [OPTIONS]`

###### **Options:**

* `-b`, `--branch <BRANCH>` — Fetch only some of the branches

   By default, the specified name matches exactly. Use `glob:` prefix to expand `*` as a glob. The other wildcard characters aren't supported.

  Default value: `glob:*`
* `--remote <remote>` — The remote to fetch from (only named remotes are supported, can be repeated)
* `--all-remotes` — Fetch from all remotes



## `jj git import`

Update repo with changes made in the underlying Git repo

If a working-copy commit gets abandoned, it will be given a new, empty commit. This is true in general; it is not specific to this command.

**Usage:** `jj git import`



## `jj git init`

Create a new Git backed repo

**Usage:** `jj git init [OPTIONS] [DESTINATION]`

###### **Arguments:**

* `<DESTINATION>` — The destination directory where the `jj` repo will be created. If the directory does not exist, it will be created. If no directory is given, the current directory is used.

   By default the `git` repo is under `$destination/.jj`

  Default value: `.`

###### **Options:**

* `--colocate` — Specifies that the `jj` repo should also be a valid `git` repo, allowing the use of both `jj` and `git` commands in the same directory.

   This is done by placing the backing git repo into a `.git` directory in the root of the `jj` repo along with the `.jj` directory. If the `.git` directory already exists, all the existing commits will be imported.

   This option is mutually exclusive with `--git-repo`.
* `--git-repo <GIT_REPO>` — Specifies a path to an **existing** git repository to be used as the backing git repo for the newly created `jj` repo.

   If the specified `--git-repo` path happens to be the same as the `jj` repo path (both .jj and .git directories are in the same working directory), then both `jj` and `git` commands will work on the same repo. This is called a co-located repo.

   This option is mutually exclusive with `--colocate`.



## `jj git push`

Push to a Git remote

By default, pushes any branches pointing to `remote_branches(remote=<remote>)..@`. Use `--branch` to push specific branches. Use `--all` to push all branches. Use `--change` to generate branch names based on the change IDs of specific commits.

Before the command actually moves, creates, or deletes a remote branch, it makes several [safety checks]. If there is a problem, you may need to run `jj git fetch --remote <remote name>` and/or resolve some [branch conflicts].

[safety checks]: https://martinvonz.github.io/jj/latest/branches/#pushing-branches-safety-checks

[branch conflicts]: https://martinvonz.github.io/jj/latest/branches/#conflicts

**Usage:** `jj git push [OPTIONS]`

###### **Options:**

* `--remote <REMOTE>` — The remote to push to (only named remotes are supported)
* `-b`, `--branch <BRANCH>` — Push only this branch, or branches matching a pattern (can be repeated)

   By default, the specified name matches exactly. Use `glob:` prefix to select branches by wildcard pattern. For details, see https://martinvonz.github.io/jj/latest/revsets#string-patterns.
* `--all` — Push all branches (including deleted branches)
* `--tracked` — Push all tracked branches (including deleted branches)

   This usually means that the branch was already pushed to or fetched from the relevant remote. For details, see https://martinvonz.github.io/jj/latest/branches#remotes-and-tracked-branches
* `--deleted` — Push all deleted branches

   Only tracked branches can be successfully deleted on the remote. A warning will be printed if any untracked branches on the remote correspond to missing local branches.
* `--allow-empty-description` — Allow pushing commits with empty descriptions
* `-r`, `--revisions <REVISIONS>` — Push branches pointing to these commits (can be repeated)
* `-c`, `--change <CHANGE>` — Push this commit by creating a branch based on its change ID (can be repeated)
* `--dry-run` — Only display what will change on the remote



## `jj git remote`

Manage Git remotes

The Git repo will be a bare git repo stored inside the `.jj/` directory.

**Usage:** `jj git remote <COMMAND>`

###### **Subcommands:**

* `add` — Add a Git remote
* `list` — List Git remotes
* `remove` — Remove a Git remote and forget its branches
* `rename` — Rename a Git remote
* `set-url` — Set the URL of a Git remote



## `jj git remote add`

Add a Git remote

**Usage:** `jj git remote add <REMOTE> <URL>`

###### **Arguments:**

* `<REMOTE>` — The remote's name
* `<URL>` — The remote's URL



## `jj git remote list`

List Git remotes

**Usage:** `jj git remote list`



## `jj git remote remove`

Remove a Git remote and forget its branches

**Usage:** `jj git remote remove <REMOTE>`

###### **Arguments:**

* `<REMOTE>` — The remote's name



## `jj git remote rename`

Rename a Git remote

**Usage:** `jj git remote rename <OLD> <NEW>`

###### **Arguments:**

* `<OLD>` — The name of an existing remote
* `<NEW>` — The desired name for `old`



## `jj git remote set-url`

Set the URL of a Git remote

**Usage:** `jj git remote set-url <REMOTE> <URL>`

###### **Arguments:**

* `<REMOTE>` — The remote's name
* `<URL>` — The desired url for `remote`



## `jj init`

Create a new repo in the given directory

If the given directory does not exist, it will be created. If no directory is given, the current directory is used.

**Usage:** `jj init [DESTINATION]`

###### **Arguments:**

* `<DESTINATION>` — The destination directory

  Default value: `.`



## `jj interdiff`

Compare the changes of two commits

This excludes changes from other commits by temporarily rebasing `--from` onto `--to`'s parents. If you wish to compare the same change across versions, consider `jj obslog -p` instead.

**Usage:** `jj interdiff [OPTIONS] <--from <FROM>|--to <TO>> [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Restrict the diff to these paths

###### **Options:**

* `--from <FROM>` — Show changes from this revision
* `--to <TO>` — Show changes to this revision
* `-s`, `--summary` — For each path, show only whether it was modified, added, or deleted
* `--stat` — Show a histogram of the changes
* `--types` — For each path, show only its type before and after

   The diff is shown as two letters. The first letter indicates the type before and the second letter indicates the type after. '-' indicates that the path was not present, 'F' represents a regular file, `L' represents a symlink, 'C' represents a conflict, and 'G' represents a Git submodule.
* `--name-only` — For each path, show only its path

   Typically useful for shell commands like: `jj diff -r @- --name_only | xargs perl -pi -e's/OLD/NEW/g`
* `--git` — Show a Git-format diff
* `--color-words` — Show a word-level diff with changes indicated only by color
* `--tool <TOOL>` — Generate diff by external command
* `--context <CONTEXT>` — Number of lines of context to show



## `jj log`

Show revision history

Renders a graphical view of the project's history, ordered with children before parents. By default, the output only includes mutable revisions, along with some additional revisions for context.

Spans of revisions that are not included in the graph per `--revisions` are rendered as a synthetic node labeled "(elided revisions)".

**Usage:** `jj log [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Show revisions modifying the given paths

###### **Options:**

* `-r`, `--revisions <REVISIONS>` — Which revisions to show. If no paths nor revisions are specified, this defaults to the `revsets.log` setting, or `@ | ancestors(immutable_heads().., 2) | trunk()` if it is not set
* `--reversed` — Show revisions in the opposite order (older revisions first)
* `-n`, `--limit <LIMIT>` — Limit number of revisions to show

   Applied after revisions are filtered and reordered.
* `--no-graph` — Don't show the graph, show a flat list of revisions
* `-T`, `--template <TEMPLATE>` — Render each revision using the given template

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md
* `-p`, `--patch` — Show patch
* `-s`, `--summary` — For each path, show only whether it was modified, added, or deleted
* `--stat` — Show a histogram of the changes
* `--types` — For each path, show only its type before and after

   The diff is shown as two letters. The first letter indicates the type before and the second letter indicates the type after. '-' indicates that the path was not present, 'F' represents a regular file, `L' represents a symlink, 'C' represents a conflict, and 'G' represents a Git submodule.
* `--name-only` — For each path, show only its path

   Typically useful for shell commands like: `jj diff -r @- --name_only | xargs perl -pi -e's/OLD/NEW/g`
* `--git` — Show a Git-format diff
* `--color-words` — Show a word-level diff with changes indicated only by color
* `--tool <TOOL>` — Generate diff by external command
* `--context <CONTEXT>` — Number of lines of context to show



## `jj new`

Create a new, empty change and (by default) edit it in the working copy

By default, `jj` will edit the new change, making the working copy represent the new commit. This can be avoided with `--no-edit`.

Note that you can create a merge commit by specifying multiple revisions as argument. For example, `jj new main @` will create a new commit with the `main` branch and the working copy as parents.

For more information, see https://github.com/martinvonz/jj/blob/main/docs/working-copy.md.

**Usage:** `jj new [OPTIONS] [REVISIONS]...`

###### **Arguments:**

* `<REVISIONS>` — Parent(s) of the new change

  Default value: `@`

###### **Options:**

* `-m`, `--message <MESSAGE>` — The change description to use
* `--no-edit` — Do not edit the newly created change
* `-A`, `--insert-after <INSERT_AFTER>` — Insert the new change after the given commit(s)
* `-B`, `--insert-before <INSERT_BEFORE>` — Insert the new change before the given commit(s)



## `jj next`

Move the working-copy commit to the child revision

The command creates a new empty working copy revision that is the child of a
descendant `offset` revisions ahead of the parent of the current working
copy.

For example, when the offset is 1:

```text
D        D @
|        |/
C @  =>  C
|/       |
B        B
```

If `--edit` is passed, the working copy revision is changed to the child of
the current working copy revision.

```text
D        D
|        |
C        C
|        |
B   =>   @
|        |
@        A
```
If your working-copy commit already has visible children, then `--edit` is
implied.

**Usage:** `jj next [OPTIONS] [OFFSET]`

###### **Arguments:**

* `<OFFSET>` — How many revisions to move forward. Advances to the next child by default

  Default value: `1`

###### **Options:**

* `-e`, `--edit` — Instead of creating a new working-copy commit on top of the target commit (like `jj new`), edit the target commit directly (like `jj edit`)
* `--conflict` — Jump to the next conflicted descendant



## `jj obslog`

Show how a change has evolved over time

Lists the previous commits which a change has pointed to. The current commit of a change evolves when the change is updated, rebased, etc.

Name is derived from Merciual's obsolescence markers.

**Usage:** `jj obslog [OPTIONS]`

###### **Options:**

* `-r`, `--revision <REVISION>`

  Default value: `@`
* `-n`, `--limit <LIMIT>` — Limit number of revisions to show
* `--no-graph` — Don't show the graph, show a flat list of revisions
* `-T`, `--template <TEMPLATE>` — Render each revision using the given template

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md
* `-p`, `--patch` — Show patch compared to the previous version of this change

   If the previous version has different parents, it will be temporarily rebased to the parents of the new version, so the diff is not contaminated by unrelated changes.
* `-s`, `--summary` — For each path, show only whether it was modified, added, or deleted
* `--stat` — Show a histogram of the changes
* `--types` — For each path, show only its type before and after

   The diff is shown as two letters. The first letter indicates the type before and the second letter indicates the type after. '-' indicates that the path was not present, 'F' represents a regular file, `L' represents a symlink, 'C' represents a conflict, and 'G' represents a Git submodule.
* `--name-only` — For each path, show only its path

   Typically useful for shell commands like: `jj diff -r @- --name_only | xargs perl -pi -e's/OLD/NEW/g`
* `--git` — Show a Git-format diff
* `--color-words` — Show a word-level diff with changes indicated only by color
* `--tool <TOOL>` — Generate diff by external command
* `--context <CONTEXT>` — Number of lines of context to show



## `jj operation`

Commands for working with the operation log

For information about the operation log, see https://github.com/martinvonz/jj/blob/main/docs/operation-log.md.

**Usage:** `jj operation <COMMAND>`

###### **Subcommands:**

* `abandon` — Abandon operation history
* `log` — Show the operation log
* `restore` — Create a new operation that restores the repo to an earlier state
* `undo` — Create a new operation that undoes an earlier operation



## `jj operation abandon`

Abandon operation history

To discard old operation history, use `jj op abandon ..<operation ID>`. It will abandon the specified operation and all its ancestors. The descendants will be reparented onto the root operation.

To discard recent operations, use `jj op restore <operation ID>` followed by `jj op abandon <operation ID>..@-`.

The abandoned operations, commits, and other unreachable objects can later be garbage collected by using `jj util gc` command.

**Usage:** `jj operation abandon <OPERATION>`

###### **Arguments:**

* `<OPERATION>` — The operation or operation range to abandon



## `jj operation log`

Show the operation log

**Usage:** `jj operation log [OPTIONS]`

###### **Options:**

* `-n`, `--limit <LIMIT>` — Limit number of operations to show
* `--no-graph` — Don't show the graph, show a flat list of operations
* `-T`, `--template <TEMPLATE>` — Render each operation using the given template

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md



## `jj operation restore`

Create a new operation that restores the repo to an earlier state

This restores the repo to the state at the specified operation, effectively undoing all later operations. It does so by creating a new operation.

**Usage:** `jj operation restore [OPTIONS] <OPERATION>`

###### **Arguments:**

* `<OPERATION>` — The operation to restore to

   Use `jj op log` to find an operation to restore to. Use e.g. `jj --at-op=<operation ID> log` before restoring to an operation to see the state of the repo at that operation.

###### **Options:**

* `--what <WHAT>` — What portions of the local state to restore (can be repeated)

   This option is EXPERIMENTAL.

  Default values: `repo`, `remote-tracking`

  Possible values:
  - `repo`:
    The jj repo state and local branches
  - `remote-tracking`:
    The remote-tracking branches. Do not restore these if you'd like to push after the undo




## `jj operation undo`

Create a new operation that undoes an earlier operation

This undoes an individual operation by applying the inverse of the operation.

**Usage:** `jj operation undo [OPTIONS] [OPERATION]`

###### **Arguments:**

* `<OPERATION>` — The operation to undo

   Use `jj op log` to find an operation to undo.

  Default value: `@`

###### **Options:**

* `--what <WHAT>` — What portions of the local state to restore (can be repeated)

   This option is EXPERIMENTAL.

  Default values: `repo`, `remote-tracking`

  Possible values:
  - `repo`:
    The jj repo state and local branches
  - `remote-tracking`:
    The remote-tracking branches. Do not restore these if you'd like to push after the undo




## `jj parallelize`

Parallelize revisions by making them siblings

Running `jj parallelize 1::2` will transform the history like this:
```text
3
|             3
2            / \
|    ->     1   2
1            \ /
|             0
0
```

The command effectively says "these revisions are actually independent",
meaning that they should no longer be ancestors/descendants of each other.
However, revisions outside the set that were previously ancestors of a
revision in the set will remain ancestors of it. For example, revision 0
above remains an ancestor of both 1 and 2. Similarly,
revisions outside the set that were previously descendants of a revision
in the set will remain descendants of it. For example, revision 3 above
remains a descendant of both 1 and 2.

Therefore, `jj parallelize '1 | 3'` is a no-op. That's because 2, which is
not in the target set, was a descendant of 1 before, so it remains a
descendant, and it was an ancestor of 3 before, so it remains an ancestor.

**Usage:** `jj parallelize [REVISIONS]...`

###### **Arguments:**

* `<REVISIONS>` — Revisions to parallelize



## `jj prev`

Change the working copy revision relative to the parent revision

The command creates a new empty working copy revision that is the child of
an ancestor `offset` revisions behind the parent of the current working
copy.

For example, when the offset is 1:

```text
D @      D
|/       |
A   =>   A @
|        |/
B        B
```

If `--edit` is passed, the working copy revision is changed to the parent of
the current working copy revision.

```text
D @      D
|/       |
C   =>   @
|        |
B        B
|        |
A        A
```
If the working copy revision already has visible children, then `--edit` is
implied.

**Usage:** `jj prev [OPTIONS] [OFFSET]`

###### **Arguments:**

* `<OFFSET>` — How many revisions to move backward. Moves to the parent by default

  Default value: `1`

###### **Options:**

* `-e`, `--edit` — Edit the parent directly, instead of moving the working-copy commit
* `--conflict` — Jump to the previous conflicted ancestor



## `jj rebase`

Move revisions to different parent(s)

There are three different ways of specifying which revisions to rebase:
`-b` to rebase a whole branch, `-s` to rebase a revision and its
descendants, and `-r` to rebase a single commit. If none of them is
specified, it defaults to `-b @`.

With `-s`, the command rebases the specified revision and its descendants
onto the destination. For example, `jj rebase -s M -d O` would transform
your history like this (letters followed by an apostrophe are post-rebase
versions):

```text
O           N'
|           |
| N         M'
| |         |
| M         O
| |    =>   |
| | L       | L
| |/        | |
| K         | K
|/          |/
J           J
```

With `-b`, the command rebases the whole "branch" containing the specified
revision. A "branch" is the set of commits that includes:

* the specified revision and ancestors that are not also ancestors of the
  destination
* all descendants of those commits

In other words, `jj rebase -b X -d Y` rebases commits in the revset
`(Y..X)::` (which is equivalent to `jj rebase -s 'roots(Y..X)' -d Y` for a
single root). For example, either `jj rebase -b L -d O` or `jj rebase -b M
-d O` would transform your history like this (because `L` and `M` are on the
same "branch", relative to the destination):

```text
O           N'
|           |
| N         M'
| |         |
| M         | L'
| |    =>   |/
| | L       K'
| |/        |
| K         O
|/          |
J           J
```

With `-r`, the command rebases only the specified revisions onto the
destination. Any "hole" left behind will be filled by rebasing descendants
onto the specified revision's parent(s). For example, `jj rebase -r K -d M`
would transform your history like this:

```text
M          K'
|          |
| L        M
| |   =>   |
| K        | L'
|/         |/
J          J
```

Note that you can create a merge commit by repeating the `-d` argument.
For example, if you realize that commit L actually depends on commit M in
order to work (in addition to its current parent K), you can run `jj rebase
-s L -d K -d M`:

```text
M          L'
|          |\
| L        M |
| |   =>   | |
| K        | K
|/         |/
J          J
```

If a working-copy commit gets abandoned, it will be given a new, empty
commit. This is true in general; it is not specific to this command.

**Usage:** `jj rebase [OPTIONS] <--destination <DESTINATION>|--insert-after <INSERT_AFTER>|--insert-before <INSERT_BEFORE>>`

###### **Options:**

* `-b`, `--branch <BRANCH>` — Rebase the whole branch relative to destination's ancestors (can be repeated)

   `jj rebase -b=br -d=dst` is equivalent to `jj rebase '-s=roots(dst..br)' -d=dst`.

   If none of `-b`, `-s`, or `-r` is provided, then the default is `-b @`.
* `-s`, `--source <SOURCE>` — Rebase specified revision(s) together with their trees of descendants (can be repeated)

   Each specified revision will become a direct child of the destination revision(s), even if some of the source revisions are descendants of others.

   If none of `-b`, `-s`, or `-r` is provided, then the default is `-b @`.
* `-r`, `--revisions <REVISIONS>` — Rebase the given revisions, rebasing descendants onto this revision's parent(s)

   Unlike `-s` or `-b`, you may `jj rebase -r` a revision `A` onto a descendant of `A`.

   If none of `-b`, `-s`, or `-r` is provided, then the default is `-b @`.
* `-d`, `--destination <DESTINATION>` — The revision(s) to rebase onto (can be repeated to create a merge commit)
* `-A`, `--insert-after <INSERT_AFTER>` — The revision(s) to insert after (can be repeated to create a merge commit)

   Only works with `-r`.
* `-B`, `--insert-before <INSERT_BEFORE>` — The revision(s) to insert before (can be repeated to create a merge commit)

   Only works with `-r`.
* `--skip-emptied` — If true, when rebasing would produce an empty commit, the commit is abandoned. It will not be abandoned if it was already empty before the rebase. Will never skip merge commits with multiple non-empty parents



## `jj resolve`

Resolve a conflicted file with an external merge tool

Only conflicts that can be resolved with a 3-way merge are supported. See docs for merge tool configuration instructions.

Note that conflicts can also be resolved without using this command. You may edit the conflict markers in the conflicted file directly with a text editor.

**Usage:** `jj resolve [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Restrict to these paths when searching for a conflict to resolve. We will attempt to resolve the first conflict we can find. You can use the `--list` argument to find paths to use here

###### **Options:**

* `-r`, `--revision <REVISION>`

  Default value: `@`
* `-l`, `--list` — Instead of resolving one conflict, list all the conflicts
* `--tool <NAME>` — Specify 3-way merge tool to be used



## `jj restore`

Restore paths from another revision

That means that the paths get the same content in the destination (`--to`) as they had in the source (`--from`). This is typically used for undoing changes to some paths in the working copy (`jj restore <paths>`).

If only one of `--from` or `--to` is specified, the other one defaults to the working copy.

When neither `--from` nor `--to` is specified, the command restores into the working copy from its parent(s). `jj restore` without arguments is similar to `jj abandon`, except that it leaves an empty revision with its description and other metadata preserved.

See `jj diffedit` if you'd like to restore portions of files rather than entire files.

**Usage:** `jj restore [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Restore only these paths (instead of all paths)

###### **Options:**

* `--from <FROM>` — Revision to restore from (source)
* `--to <TO>` — Revision to restore into (destination)
* `-c`, `--changes-in <REVISION>` — Undo the changes in a revision as compared to the merge of its parents.

   This undoes the changes that can be seen with `jj diff -r REVISION`. If `REVISION` only has a single parent, this option is equivalent to `jj restore --to REVISION --from REVISION-`.

   The default behavior of `jj restore` is equivalent to `jj restore --changes-in @`.



## `jj root`

Show the current workspace root directory

**Usage:** `jj root`



## `jj show`

Show commit description and changes in a revision

**Usage:** `jj show [OPTIONS] [REVISION]`

###### **Arguments:**

* `<REVISION>` — Show changes in this revision, compared to its parent(s)

  Default value: `@`

###### **Options:**

* `-T`, `--template <TEMPLATE>` — Render a revision using the given template

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md
* `-s`, `--summary` — For each path, show only whether it was modified, added, or deleted
* `--stat` — Show a histogram of the changes
* `--types` — For each path, show only its type before and after

   The diff is shown as two letters. The first letter indicates the type before and the second letter indicates the type after. '-' indicates that the path was not present, 'F' represents a regular file, `L' represents a symlink, 'C' represents a conflict, and 'G' represents a Git submodule.
* `--name-only` — For each path, show only its path

   Typically useful for shell commands like: `jj diff -r @- --name_only | xargs perl -pi -e's/OLD/NEW/g`
* `--git` — Show a Git-format diff
* `--color-words` — Show a word-level diff with changes indicated only by color
* `--tool <TOOL>` — Generate diff by external command
* `--context <CONTEXT>` — Number of lines of context to show



## `jj sparse`

Manage which paths from the working-copy commit are present in the working copy

**Usage:** `jj sparse <COMMAND>`

###### **Subcommands:**

* `edit` — Start an editor to update the patterns that are present in the working copy
* `list` — List the patterns that are currently present in the working copy
* `reset` — Reset the patterns to include all files in the working copy
* `set` — Update the patterns that are present in the working copy



## `jj sparse edit`

Start an editor to update the patterns that are present in the working copy

**Usage:** `jj sparse edit`



## `jj sparse list`

List the patterns that are currently present in the working copy

By default, a newly cloned or initialized repo will have have a pattern matching all files from the repo root. That pattern is rendered as `.` (a single period).

**Usage:** `jj sparse list`



## `jj sparse reset`

Reset the patterns to include all files in the working copy

**Usage:** `jj sparse reset`



## `jj sparse set`

Update the patterns that are present in the working copy

For example, if all you need is the `README.md` and the `lib/` directory, use `jj sparse set --clear --add README.md --add lib`. If you no longer need the `lib` directory, use `jj sparse set --remove lib`.

**Usage:** `jj sparse set [OPTIONS]`

###### **Options:**

* `--add <ADD>` — Patterns to add to the working copy
* `--remove <REMOVE>` — Patterns to remove from the working copy
* `--clear` — Include no files in the working copy (combine with --add)



## `jj split`

Split a revision in two

Starts a [diff editor] on the changes in the revision. Edit the right side of the diff until it has the content you want in the first revision. Once you close the editor, your edited content will replace the previous revision. The remaining changes will be put in a new revision on top.

[diff editor]: https://martinvonz.github.io/jj/latest/config/#editing-diffs

If the change you split had a description, you will be asked to enter a change description for each commit. If the change did not have a description, the second part will not get a description, and you will be asked for a description only for the first part.

Splitting an empty commit is not supported because the same effect can be achieved with `jj new`.

**Usage:** `jj split [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Put these paths in the first commit

###### **Options:**

* `-i`, `--interactive` — Interactively choose which parts to split. This is the default if no paths are provided
* `--tool <NAME>` — Specify diff editor to be used (implies --interactive)
* `-r`, `--revision <REVISION>` — The revision to split

  Default value: `@`
* `-p`, `--parallel` — Split the revision into two parallel revisions instead of a parent and child



## `jj squash`

Move changes from a revision into another revision

With the `-r` option, moves the changes from the specified revision to the parent revision. Fails if there are several parent revisions (i.e., the given revision is a merge).

With the `--from` and/or `--into` options, moves changes from/to the given revisions. If either is left out, it defaults to the working-copy commit. For example, `jj squash --into @--` moves changes from the working-copy commit to the grandparent.

If, after moving changes out, the source revision is empty compared to its parent(s), and `--keep-emptied` is not set, it will be abandoned. Without `--interactive` or paths, the source revision will always be empty.

If the source became empty and both the source and destination had a non-empty description, you will be asked for the combined description. If either was empty, then the other one will be used.

If a working-copy commit gets abandoned, it will be given a new, empty commit. This is true in general; it is not specific to this command.

**Usage:** `jj squash [OPTIONS] [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Move only changes to these paths (instead of all paths)

###### **Options:**

* `-r`, `--revision <REVISION>` — Revision to squash into its parent (default: @)
* `--from <FROM>` — Revision(s) to squash from (default: @)
* `--into <INTO>` — Revision to squash into (default: @)
* `-m`, `--message <MESSAGE>` — The description to use for squashed revision (don't open editor)
* `-u`, `--use-destination-message` — Use the description of the destination revision and discard the description(s) of the source revision(s)
* `-i`, `--interactive` — Interactively choose which parts to squash
* `--tool <NAME>` — Specify diff editor to be used (implies --interactive)
* `--keep-emptied` — The source revision will not be abandoned



## `jj status`

Show high-level repo status

This includes:

* The working copy commit and its (first) parent, and a summary of the changes between them

* Conflicted branches (see https://github.com/martinvonz/jj/blob/main/docs/branches.md)

**Usage:** `jj status [PATHS]...`

###### **Arguments:**

* `<PATHS>` — Restrict the status display to these paths



## `jj tag`

Manage tags

**Usage:** `jj tag <COMMAND>`

###### **Subcommands:**

* `list` — List tags



## `jj tag list`

List tags

**Usage:** `jj tag list [OPTIONS] [NAMES]...`

###### **Arguments:**

* `<NAMES>` — Show tags whose local name matches

   By default, the specified name matches exactly. Use `glob:` prefix to select tags by wildcard pattern. For details, see https://github.com/martinvonz/jj/blob/main/docs/revsets.md#string-patterns.

###### **Options:**

* `-T`, `--template <TEMPLATE>` — Render each tag using the given template

   All 0-argument methods of the `RefName` type are available as keywords.

   For the syntax, see https://github.com/martinvonz/jj/blob/main/docs/templates.md



## `jj util`

Infrequently used commands such as for generating shell completions

**Usage:** `jj util <COMMAND>`

###### **Subcommands:**

* `completion` — Print a command-line-completion script
* `gc` — Run backend-dependent garbage collection
* `mangen` — Print a ROFF (manpage)
* `markdown-help` — Print the CLI help for all subcommands in Markdown
* `config-schema` — Print the JSON schema for the jj TOML config format



## `jj util completion`

Print a command-line-completion script

Apply it by running one of these:

- Bash: `source <(jj util completion bash)`
- Fish: `jj util completion fish | source`
- Nushell:
    ```nu
    jj util completion nushell | save "completions-jj.nu"
    use "completions-jj.nu" *  # Or `source "completions-jj.nu"`
    ```
- Zsh:
    ```shell
    autoload -U compinit
    compinit
    source <(jj util completion zsh)
    ```

**Usage:** `jj util completion [SHELL]`

###### **Arguments:**

* `<SHELL>`

  Possible values: `bash`, `elvish`, `fish`, `nushell`, `power-shell`, `zsh`




## `jj util gc`

Run backend-dependent garbage collection

**Usage:** `jj util gc [OPTIONS]`

###### **Options:**

* `--expire <EXPIRE>` — Time threshold

   By default, only obsolete objects and operations older than 2 weeks are pruned.

   Only the string "now" can be passed to this parameter. Support for arbitrary absolute and relative timestamps will come in a subsequent release.



## `jj util mangen`

Print a ROFF (manpage)

**Usage:** `jj util mangen`



## `jj util markdown-help`

Print the CLI help for all subcommands in Markdown

**Usage:** `jj util markdown-help`



## `jj util config-schema`

Print the JSON schema for the jj TOML config format

**Usage:** `jj util config-schema`



## `jj undo`

Undo an operation (shortcut for `jj op undo`)

**Usage:** `jj undo [OPTIONS] [OPERATION]`

###### **Arguments:**

* `<OPERATION>` — The operation to undo

   Use `jj op log` to find an operation to undo.

  Default value: `@`

###### **Options:**

* `--what <WHAT>` — What portions of the local state to restore (can be repeated)

   This option is EXPERIMENTAL.

  Default values: `repo`, `remote-tracking`

  Possible values:
  - `repo`:
    The jj repo state and local branches
  - `remote-tracking`:
    The remote-tracking branches. Do not restore these if you'd like to push after the undo




## `jj unsquash`

Move changes from a revision's parent into the revision

After moving the changes out of the parent, the child revision will have the same content state as before. If moving the change out of the parent change made it empty compared to its parent, it will be abandoned. Without `--interactive`, the parent change will always become empty.

If the source became empty and both the source and destination had a non-empty description, you will be asked for the combined description. If either was empty, then the other one will be used.

If a working-copy commit gets abandoned, it will be given a new, empty commit. This is true in general; it is not specific to this command.

**Usage:** `jj unsquash [OPTIONS]`

###### **Options:**

* `-r`, `--revision <REVISION>`

  Default value: `@`
* `-i`, `--interactive` — Interactively choose which parts to unsquash
* `--tool <NAME>` — Specify diff editor to be used (implies --interactive)



## `jj untrack`

Stop tracking specified paths in the working copy

**Usage:** `jj untrack <PATHS>...`

###### **Arguments:**

* `<PATHS>` — Paths to untrack. They must already be ignored.

   The paths could be ignored via a .gitignore or .git/info/exclude (in colocated repos).



## `jj version`

Display version information

**Usage:** `jj version`



## `jj workspace`

Commands for working with workspaces

Workspaces let you add additional working copies attached to the same repo. A common use case is so you can run a slow build or test in one workspace while you're continuing to write code in another workspace.

Each workspace has its own working-copy commit. When you have more than one workspace attached to a repo, they are indicated by `<workspace name>@` in `jj log`.

Each workspace also has own sparse patterns.

**Usage:** `jj workspace <COMMAND>`

###### **Subcommands:**

* `add` — Add a workspace
* `forget` — Stop tracking a workspace's working-copy commit in the repo
* `list` — List workspaces
* `root` — Show the current workspace root directory
* `update-stale` — Update a workspace that has become stale



## `jj workspace add`

Add a workspace

Sparse patterns will be copied over from the current workspace.

**Usage:** `jj workspace add [OPTIONS] <DESTINATION>`

###### **Arguments:**

* `<DESTINATION>` — Where to create the new workspace

###### **Options:**

* `--name <NAME>` — A name for the workspace

   To override the default, which is the basename of the destination directory.
* `-r`, `--revision <REVISION>` — A list of parent revisions for the working-copy commit of the newly created workspace. You may specify nothing, or any number of parents.

   If no revisions are specified, the new workspace will be created, and its working-copy commit will exist on top of the parent(s) of the working-copy commit in the current workspace, i.e. they will share the same parent(s).

   If any revisions are specified, the new workspace will be created, and the new working-copy commit will be created with all these revisions as parents, i.e. the working-copy commit will exist as if you had run `jj new r1 r2 r3 ...`.



## `jj workspace forget`

Stop tracking a workspace's working-copy commit in the repo

The workspace will not be touched on disk. It can be deleted from disk before or after running this command.

**Usage:** `jj workspace forget [WORKSPACES]...`

###### **Arguments:**

* `<WORKSPACES>` — Names of the workspaces to forget. By default, forgets only the current workspace



## `jj workspace list`

List workspaces

**Usage:** `jj workspace list`



## `jj workspace root`

Show the current workspace root directory

**Usage:** `jj workspace root`



## `jj workspace update-stale`

Update a workspace that has become stale

For information about stale working copies, see https://github.com/martinvonz/jj/blob/main/docs/working-copy.md.

**Usage:** `jj workspace update-stale`



<hr/>

<small><i>
    This document was generated automatically by
    <a href="https://crates.io/crates/clap-markdown"><code>clap-markdown</code></a>.
</i></small>