Skip to content

Warning

This CLI reference is experimental. It is automatically generated, but does not match the `jj help` output exactly.

Run `jj help <COMMAND>` for more authoritative documentation.

If you see a significant difference, feel free to file a bug, or a PR to note the difference here.

# Command-Line Help for `jj`

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

Command Overview:

- `jj`↴
- `jj abandon`↴
- `jj absorb`↴
- `jj arrange`↴
- `jj bisect`↴
- `jj bisect run`↴
- `jj bookmark`↴
- `jj bookmark advance`↴
- `jj bookmark create`↴
- `jj bookmark delete`↴
- `jj bookmark forget`↴
- `jj bookmark list`↴
- `jj bookmark move`↴
- `jj bookmark rename`↴
- `jj bookmark set`↴
- `jj bookmark track`↴
- `jj bookmark untrack`↴
- `jj commit`↴
- `jj config`↴
- `jj config edit`↴
- `jj config get`↴
- `jj config list`↴
- `jj config path`↴
- `jj config set`↴
- `jj config unset`↴
- `jj describe`↴
- `jj diff`↴
- `jj diffedit`↴
- `jj duplicate`↴
- `jj edit`↴
- `jj evolog`↴
- `jj file`↴
- `jj file annotate`↴
- `jj file chmod`↴
- `jj file list`↴
- `jj file search`↴
- `jj file show`↴
- `jj file track`↴
- `jj file untrack`↴
- `jj fix`↴
- `jj gerrit`↴
- `jj gerrit upload`↴
- `jj git`↴
- `jj git clone`↴
- `jj git colocation`↴
- `jj git colocation disable`↴
- `jj git colocation enable`↴
- `jj git colocation status`↴
- `jj git export`↴
- `jj git fetch`↴
- `jj git import`↴
- `jj git init`↴
- `jj git push`↴
- `jj git remote`↴
- `jj git remote add`↴
- `jj git remote list`↴
- `jj git remote remove`↴
- `jj git remote rename`↴
- `jj git remote set-url`↴
- `jj git root`↴
- `jj help`↴
- `jj interdiff`↴
- `jj log`↴
- `jj metaedit`↴
- `jj new`↴
- `jj next`↴
- `jj operation`↴
- `jj operation abandon`↴
- `jj operation diff`↴
- `jj operation integrate`↴
- `jj operation log`↴
- `jj operation restore`↴
- `jj operation revert`↴
- `jj operation show`↴
- `jj parallelize`↴
- `jj prev`↴
- `jj rebase`↴
- `jj redo`↴
- `jj resolve`↴
- `jj restore`↴
- `jj revert`↴
- `jj root`↴
- `jj show`↴
- `jj sign`↴
- `jj simplify-parents`↴
- `jj sparse`↴
- `jj sparse edit`↴
- `jj sparse list`↴
- `jj sparse reset`↴
- `jj sparse set`↴
- `jj split`↴
- `jj squash`↴
- `jj status`↴
- `jj tag`↴
- `jj tag delete`↴
- `jj tag list`↴
- `jj tag set`↴
- `jj undo`↴
- `jj unsign`↴
- `jj util`↴
- `jj util completion`↴
- `jj util config-schema`↴
- `jj util exec`↴
- `jj util gc`↴
- `jj util install-man-pages`↴
- `jj util markdown-help`↴
- `jj util snapshot`↴
- `jj version`↴
- `jj workspace`↴
- `jj workspace add`↴
- `jj workspace forget`↴
- `jj workspace list`↴
- `jj workspace rename`↴
- `jj workspace root`↴
- `jj workspace update-stale`↴

## `jj`

Jujutsu (An experimental VCS)

To get started, see the tutorial [`jj help -k tutorial`].

Usage: `jj [OPTIONS] [COMMAND]`

'jj help --help' lists available keywords. Use 'jj help -k' to show help for one of these keywords.

###### Subcommands:

- `abandon` — Abandon a revision
- `absorb` — Move changes from a revision into the stack of mutable revisions
- `arrange` — Interactively arrange the commit graph
- `bisect` — Find a bad revision by bisection
- `bookmark` — Manage bookmarks [default alias: b]
- `commit` — Update the description and create a new change on top [default alias: ci]
- `config` — Manage config options
- `describe` — Update the change description or other metadata [default alias: desc]
- `diff` — Compare file contents between two revisions
- `diffedit` — Touch up the content changes in a revision with a diff editor
- `duplicate` — Create new changes with the same content as existing ones
- `edit` — Sets the specified revision as the working-copy revision
- `evolog` — Show how a change has evolved over time
- `file` — File operations
- `fix` — Update files with formatting fixes or other changes
- `gerrit` — Interact with Gerrit Code Review
- `git` — Commands for working with Git remotes and the underlying Git repo
- `help` — Print this message or the help of the given subcommand(s)
- `interdiff` — Show differences between the diffs of two revisions
- `log` — Show revision history
- `metaedit` — Modify the metadata of a revision without changing its content
- `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
- `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)
- `redo` — Redo the most recently undone operation
- `resolve` — Resolve conflicted files with an external merge tool
- `restore` — Restore paths from another revision
- `revert` — Apply the reverse of the given revision(s)
- `root` — Show the current workspace root directory (shortcut for `jj workspace root`)
- `show` — Show commit description and changes in a revision
- `sign` — Cryptographically sign a revision
- `simplify-parents` — Simplify parent edges for the specified revision(s)
- `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 [default alias: st]
- `tag` — Manage tags
- `undo` — Undo the last operation
- `unsign` — Drop a cryptographic signature
- `util` — Infrequently used commands such as for generating shell completions
- `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`.

- `--no-integrate-operation` — Run the command as usual but don't integrate any operations

  When this option is given, the operations will still be created as usual but they will not be integrated to the operation log. The working copy will also not be updated.

  The command will print the resulting operation ID. You can pass that to e.g. `jj --at-op` to inspect the resulting repo state, or you can pass it to `jj op restore` to restore the repo to that state. You can also pass the ID to `jj op integrate` to integrate the operation.

  Note that this does not prevent side effects outside the repo. For example, `jj git push --no-integrate-operation` will still perform the push.

- `--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>` [alias: `at-op`] — Operation to load the repo at

  Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, or at the merge of the divergent operations if any.

  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. `--at-op=@` is pretty much the same as the default except that divergent operations will never be merged.

  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.

- `--debug` — Enable debug logging

- `--color <WHEN>` — When to colorize output

  Possible values: `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 <NAME=VALUE>` — Additional configuration options (can be repeated)

  The name should be specified as TOML dotted keys. The value should be specified as a TOML expression. If string value isn't enclosed by any TOML constructs (such as array notation), quotes can be omitted.

- `--config-file <PATH>` — Additional configuration files (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] [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revision(s) to abandon (default: @) [aliases: -r]

###### Options:

- `--retain-bookmarks` — Do not delete bookmarks pointing to the revisions to abandon

  Bookmarks will be moved to the parent revisions instead.

- `--restore-descendants` — Do not modify the content of the children of the abandoned commits

## `jj absorb`

Move changes from a revision into the stack of mutable revisions

This command splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.

The source revision will be abandoned if all changes are absorbed into the destination revisions, and if the source revision has no description.

The modification made by `jj absorb` can be reviewed by `jj op show -p`.

Usage: `jj absorb [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Move only changes to these paths (instead of all paths)

###### Options:

- `-f`, `--from <REVSET>` — Source revision to absorb from

  Default value: `@`

- `-t`, `--into <REVSETS>` [alias: `to`] — Destination revisions to absorb into

  Only ancestors of the source revision will be considered.

  Default value: `mutable()`

## `jj arrange`

Interactively arrange the commit graph

Usage: `jj arrange [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revisions to arrange [aliases: -r]

  If no revisions are specified, this defaults to the `revsets.arrange` setting.

## `jj bisect`

Find a bad revision by bisection

Usage: `jj bisect <COMMAND>`

###### Subcommands:

- `run` — Run a given command to find the first bad revision

## `jj bisect run`

Run a given command to find the first bad revision.

Uses binary search to find the first bad revision. Revisions are evaluated by running a given command (see the documentation for `--command` for details).

It is assumed that if a given revision is bad, then all its descendants in the input range are also bad.

The target of the bisection can be inverted to look for the first good revision by passing `--find-good`.

Hint: You can pass your shell as evaluation command. You can then run manual tests in the shell and make sure to exit the shell with appropriate error code depending on the outcome (e.g. `exit 0` to mark the revision as good in Bash or Fish).

Example: To run `cargo test` with the changes from revision `xyz` applied:

`jj bisect run --range v1.0..main -- bash -c "jj duplicate -r xyz -B @ && cargo test"`

Usage: `jj bisect run [OPTIONS] --range <REVSETS> [COMMAND] [ARGS]...`

###### Arguments:

- `<COMMAND>` — Command to run to determine whether the bug is present

  The exit status of the command will be used to mark revisions as good or bad: status 0 means good, 125 means to skip the revision, 127 (command not found) will abort the bisection, and any other non-zero exit status means the revision is bad.

  The target's commit ID is available to the command in the `$JJ_BISECT_TARGET` environment variable.

- `<ARGS>` — Arguments to pass to the command

  Hint: Use a `--` separator to allow passing arguments starting with `-`. For example `jj bisect run --range=... -- test -f some-file`.

###### Options:

- `-r`, `--range <REVSETS>` — Range of revisions to bisect

  This is typically a range like `v1.0..main`. The heads of the range are assumed to be bad. Ancestors of the range that are not also in the range are assumed to be good.

- `--find-good` — Whether to find the first good revision instead

  Inverts the interpretation of exit statuses (excluding special exit statuses).

  Default value: `false`

## `jj bookmark`

Manage bookmarks [default alias: b]

See [`jj help -k bookmarks`] for more information.

Usage: `jj bookmark <COMMAND>`

###### Subcommands:

- `advance` — Advance the closest bookmarks to a target revision
- `create` — Create a new bookmark
- `delete` — Delete an existing bookmark and propagate the deletion to remotes on the next push
- `forget` — Forget a bookmark without marking it as a deletion to be pushed
- `list` — List bookmarks and their targets
- `move` — Move existing bookmarks to target revision
- `rename` — Rename `old` bookmark name to `new` bookmark name
- `set` — Create a new bookmark, or update an existing one by name
- `track` — Start tracking given remote bookmarks
- `untrack` — Stop tracking given remote bookmarks

## `jj bookmark advance`

Advance the closest bookmarks to a target revision

The target `--to` defaults to `revsets.bookmark-advance-to` (which defaults to `@`).

The bookmarks to advance are determined by `revsets.bookmark-advance-from` (which defaults to `heads(::to & bookmarks())`).

Note that the from revset has access to `to`.

Positional bookmark name arguments can target specific bookmarks to advance to the target, in this case the default from revset is ignored.

Example:

`jj bookmark advance --to x` - Does the equivalent of `jj bookmark move --from 'heads(::x & bookmarks())' --to x`.

Usage: `jj bookmark advance [OPTIONS] [NAMES]...`

Command Alias: `a`

###### Arguments:

- `<NAMES>` — Move bookmarks matching the given name patterns

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `-t`, `--to <REVSET>` — Move bookmarks to this revision

  Defaults to `revsets.bookmark-advance-to`.

## `jj bookmark create`

Create a new bookmark

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

Command Alias: `c`

###### Arguments:

- `<NAMES>` — The bookmarks to create

###### Options:

- `-r`, `--revision <REVSET>` [alias: `to`] — The bookmark's target revision

  Default value: `@`

## `jj bookmark delete`

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

Revisions referred to by the deleted bookmarks are not abandoned. To delete revisions as well as bookmarks, use `jj abandon`. For example, `jj abandon main..<bookmark>` will abandon revisions belonging to the `<bookmark>` branch (relative to the `main` branch.)

If you don't want the deletion of the local bookmark to propagate to any tracked remote bookmarks, use `jj bookmark forget` instead.

Usage: `jj bookmark delete <NAMES>...`

Command Alias: `d`

###### Arguments:

- `<NAMES>` — The bookmarks to delete

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

## `jj bookmark forget`

Forget a bookmark without marking it as a deletion to be pushed

If a local bookmark is forgotten, any corresponding remote bookmarks will become untracked to ensure that the forgotten bookmark will not impact remotes on future pushes.

Usage: `jj bookmark forget [OPTIONS] <NAMES>...`

Command Alias: `f`

###### Arguments:

- `<NAMES>` — The bookmarks to forget

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `--include-remotes` — When forgetting a local bookmark, also forget any corresponding remote bookmarks

  A forgotten remote bookmark will not impact remotes on future pushes. It will be recreated on future fetches if it still exists on the remote. If there is a corresponding Git-tracking remote bookmark, it will also be forgotten.

## `jj bookmark list`

List bookmarks and their targets

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

See [`jj help -k bookmarks`] for more information.

Usage: `jj bookmark list [OPTIONS] [NAMES]...`

Command Alias: `l`

###### Arguments:

- `<NAMES>` — Show bookmarks whose local name matches

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `-a`, `--all-remotes` — Show all tracked and untracked remote bookmarks including the ones whose targets are synchronized with the local bookmarks

- `--remote <REMOTE>` — Show all tracked and untracked remote bookmarks belonging to this remote

  Can be combined with `--tracked` or `--conflicted` to filter the bookmarks shown (can be repeated.)

  By default, the specified pattern matches remote names with glob syntax. You can also use other string pattern syntax.

- `-t`, `--tracked` — Show tracked remote bookmarks only

  This omits local Git-tracking bookmarks by default.

- `-c`, `--conflicted` — Show conflicted bookmarks only

- `-r`, `--revision <REVSETS>` — Show bookmarks whose local targets are in the given revisions

  Note that `-r deleted_bookmark` will not work since `deleted_bookmark` wouldn't have a local target.

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

  All 0-argument methods of the [`CommitRef` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

- `--sort <SORT_KEY>` — Sort bookmarks based on the given key (or multiple keys)

  Suffix the key with `-` to sort in descending order of the value (e.g. `--sort name-`). Note that when using multiple keys, the first key is the most significant.

  This defaults to the `ui.bookmark-list-sort-keys` setting.

  Possible values: `name`, `name-`, `author-name`, `author-name-`, `author-email`, `author-email-`, `author-date`, `author-date-`, `committer-name`, `committer-name-`, `committer-email`, `committer-email-`, `committer-date`, `committer-date-`

## `jj bookmark move`

Move existing bookmarks to target revision

Unlike `jj bookmark set`, this command cannot create new bookmarks.

If bookmark names are given, the specified bookmarks will be updated to point to the target revision.

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

Usage: `jj bookmark move [OPTIONS] <NAMES|--from <REVSETS>>`

Command Alias: `m`

###### Arguments:

- `<NAMES>` — Move bookmarks matching the given name patterns

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `-f`, `--from <REVSETS>` — Move bookmarks from the given revisions

- `-t`, `--to <REVSET>` — Move bookmarks to this revision

  Default value: `@`

- `-B`, `--allow-backwards` — Allow moving bookmarks backwards or sideways

## `jj bookmark rename`

Rename `old` bookmark name to `new` bookmark name

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

Usage: `jj bookmark rename [OPTIONS] <OLD> <NEW>`

Command Alias: `r`

###### Arguments:

- `<OLD>` — The old name of the bookmark
- `<NEW>` — The new name of the bookmark

###### Options:

- `--overwrite-existing` — Allow renaming even if the new bookmark name already exists

## `jj bookmark set`

Create a new bookmark, or update an existing one by name

If you want to move bookmarks based on their current location rather than by name, use `jj bookmark move --from <REVSETS>`.

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

Command Alias: `s`

###### Arguments:

- `<NAMES>` — The bookmarks to update

###### Options:

- `-r`, `--revision <REVSET>` [alias: `to`] — The bookmark's target revision

  Default value: `@`

- `-B`, `--allow-backwards` — Allow moving the bookmark backwards or sideways

## `jj bookmark track`

Start tracking given remote bookmarks

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

Usage: `jj bookmark track [OPTIONS] <BOOKMARK>...`

Command Alias: `t`

###### Arguments:

- `<BOOKMARK>` — Bookmark names to track

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `--remote <REMOTE>` — Remote names to track

  By default, the specified pattern matches remote names with glob syntax. You can also use other string pattern syntax.

  If no remote names are given, all remote bookmarks matching the bookmark names will be tracked.

## `jj bookmark untrack`

Stop tracking given remote bookmarks

An untracked remote bookmark is just a pointer to the last-fetched remote bookmark. It won't be imported as a local bookmark on future pulls.

If you want to forget a local bookmark while also untracking the corresponding remote bookmarks, use `jj bookmark forget` instead.

Usage: `jj bookmark untrack [OPTIONS] <BOOKMARK>...`

###### Arguments:

- `<BOOKMARK>` — Bookmark names to untrack

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `--remote <REMOTE>` — Remote names to untrack

  By default, the specified pattern matches remote names with glob syntax. You can also use other string pattern syntax.

  If no remote names are given, all remote bookmarks matching the bookmark names will be untracked.

## `jj commit`

Update the description and create a new change on top [default alias: ci]

When called without path arguments or `--interactive`, `jj commit` is equivalent to `jj describe` followed by `jj new`.

When using `--interactive` or path arguments, the selected changes stay in the current commit while the remaining changes are moved to a new working-copy commit on top. This is very similar to `jj split`. Differences include:

- `jj commit` is not interactive by default (it selects all changes).

- `jj commit` doesn't have a `-r` option. It always acts on the working-copy commit (@).

- `jj split` (without `-o`/`-A`/`-B`) will move bookmarks forward from the old change to the child change. `jj commit` doesn't move bookmarks forward.

- `jj split` allows you to move the selected changes to a different destination with `-o`/`-A`/`-B`.

Usage: `jj commit [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Put these paths in the current commit

###### Options:

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

- `--editor` — Open an editor to edit the change description

  Forces an editor to open when using `--message` to allow the message to be edited afterwards.

## `jj config`

Manage config options

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

See [`jj help -k config`] to know more about file locations, supported config options, and other details about `jj config`.

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 files, along with their values
- `path` — Print the paths to the config files
- `set` — Update a config file to set the given option to a given value
- `unset` — Update a config file to unset the given option

## `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|--workspace>`

Command Alias: `e`

###### Options:

- `--user` — Target the user-level config
- `--repo` — Target the repo-level config
- `--workspace` — Target the workspace-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>`

Command Alias: `g`

###### Arguments:

- `<NAME>`

## `jj config list`

List variables set in config files, along with their values

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

Command Alias: `l`

###### 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
- `--workspace` — Target the workspace-level config

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

  The following keywords are available in the template expression:

  - `name: String`: Config name, in TOML's "dotted key" format.
  - `value: ConfigValue`: Value to be formatted in TOML syntax.
  - `overridden: Boolean`: True if the value is shadowed by other.
  - `source: String`: Source of the value.
  - `path: String`: Path to the config file.

  Can be overridden by the `templates.config_list` setting. To see a detailed config list, use the `builtin_config_list_detailed` template.

  See [`jj help -k templates`] for more information.

## `jj config path`

Print the paths to the config files

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

If `--repo` or `--workspace` is specified and the config file does not exist, jj will generate a new config directory for this repo/workspace and print the path to the config file in that directory.

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

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

Command Alias: `p`

###### Options:

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

## `jj config set`

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

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

Command Alias: `s`

###### Arguments:

- `<NAME>`

- `<VALUE>` — New value to set

  The value should be specified as a TOML expression. If string value isn't enclosed by any TOML constructs (such as apostrophes or array notation), quotes can be omitted. Note that the value may also need shell quoting. TOML multi-line strings can be useful if the value contains apostrophes. For example, to set `foo.bar` to the string "{don't}" use `jj config set --user foo.bar "'''{don't}'''"`. This is valid in both Bash and Fish.

  Alternative, e.g. to avoid dealing with shell quoting, use `jj config edit` to edit the TOML file directly.

###### Options:

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

## `jj config unset`

Update a config file to unset the given option

Usage: `jj config unset <--user|--repo|--workspace> <NAME>`

Command Alias: `u`

###### Arguments:

- `<NAME>`

###### Options:

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

## `jj describe`

Update the change description or other metadata [default alias: desc]

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

Usage: `jj describe [OPTIONS] [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revision(s) whose description to edit (default: @) [aliases: -r]

###### Options:

- `-m`, `--message <MESSAGE>` — The change description to use (don't open editor)

  If multiple revisions are specified, the same description will be used for all of them.

- `--stdin` — Read the change description from stdin

  If multiple revisions are specified, the same description will be used for all of them.

- `--editor` — Open an editor to edit the change description

  Forces an editor to open when using `--stdin` or `--message` to allow the message to be edited afterwards.

## `jj diff`

Compare file contents between two revisions

With the `-r` option, 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 bookmark name) to the working-copy commit.

If no option is specified, it defaults to `-r @`.

Usage: `jj diff [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Restrict the diff to these paths

###### Options:

- `-r`, `--revisions <REVSETS>` — Show changes in these revisions

  If there are multiple revisions, then the total diff for all of them will be shown. For example, if you have a linear chain of revisions A..D, then `jj diff -r B::D` equals `jj diff --from A --to D`. Multiple heads and/or roots are supported, but gaps in the revset are not supported (e.g. `jj diff -r 'A|C'` in a linear chain A..C).

  If a 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.

  If none of `-r`, `-f`, or `-t` is provided, then the default is `-r @`.

- `-f`, `--from <REVSET>` — Show changes from this revision

  If none of `-r`, `-f`, or `-t` is provided, then the default is `-r @`.

- `-t`, `--to <REVSET>` — Show changes to this revision

  If none of `-r`, `-f`, or `-t` is provided, then the default is `-r @`.

- `-T`, `--template <TEMPLATE>` — Render each file diff entry using the given template

  All 0-argument methods of the [`TreeDiffEntry` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `-w`, `--ignore-all-space` — Ignore whitespace when comparing lines
- `-b`, `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

## `jj diffedit`

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

With the `-r` option, 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.

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. Unless `--restore-descendants` is used, 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. For moving changes between revisions, see `jj squash -i`.

Usage: `jj diffedit [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Edit only these paths (unmatched paths will remain unchanged)

###### Options:

- `-r`, `--revision <REVSET>` — The revision to touch up

  Defaults to @ if neither --to nor --from are specified.

- `-f`, `--from <REVSET>` — Show changes from this revision

  Defaults to @ if --to is specified.

- `-t`, `--to <REVSET>` — Edit changes in this revision

  Defaults to @ if --from is specified.

- `--tool <NAME>` — Specify diff editor to be used

- `--restore-descendants` — Preserve the content (not the diff) when rebasing descendants

  When rebasing a descendant on top of the rewritten revision, its diff compared to its parent(s) is normally preserved, i.e. the same way that descendants are always rebased. This flag makes it so the content/state is preserved instead of preserving the diff.

## `jj duplicate`

Create new changes with the same content as existing ones

When none of the `--onto`, `--insert-after`, or `--insert-before` arguments are provided, commits will be duplicated onto their existing parents or onto other newly duplicated commits.

When any of the `--onto`, `--insert-after`, or `--insert-before` arguments are provided, the roots of the specified commits will be duplicated onto the destination indicated by the arguments. Other specified commits will be duplicated onto these newly duplicated commits. If the `--insert-after` or `--insert-before` arguments are provided, the new children indicated by the arguments will be rebased onto the heads of the specified commits.

By default, the duplicated commits retain the descriptions of the originals. This can be customized with the `templates.duplicate_description` setting.

Usage: `jj duplicate [OPTIONS] [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revision(s) to duplicate (default: @) [aliases: -r]

###### Options:

- `-o`, `--onto <REVSETS>` [alias: `destination`] — The revision(s) to duplicate onto (can be repeated to create a merge commit)
- `-A`, `--insert-after <REVSETS>` [alias: `after`] — The revision(s) to insert after (can be repeated to create a merge commit)
- `-B`, `--insert-before <REVSETS>` [alias: `before`] — The revision(s) to insert before (can be repeated to create a merge commit)

## `jj edit`

Sets the specified revision as the working-copy revision

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

Usage: `jj edit <REVSET|-r <REVSET>>`

###### Arguments:

- `<REVSET>` — The commit to edit [aliases: -r]

## `jj evolog`

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.

Usage: `jj evolog [OPTIONS]`

Command Alias: `evolution-log`

###### Options:

- `-r`, `--revisions <REVSETS>` — Follow changes from these revisions

  Default value: `@`

- `-n`, `--limit <LIMIT>` — Limit number of revisions to show

  Applied after revisions are reordered topologically, but before being reversed.

- `--reversed` — Show revisions in the opposite order (older revisions first)

- `-G`, `--no-graph` — Don't show the graph, show a flat list of revisions

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

  All 0-argument methods of the [`CommitEvolutionEntry` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

  If not specified, this defaults to the `templates.evolog` setting.

- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--ignore-all-space` — Ignore whitespace when comparing lines
- `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

## `jj file`

File operations

Usage: `jj file <COMMAND>`

###### Subcommands:

- `annotate` — Show the source change for each line of the target file
- `chmod` — Sets or removes the executable bit for paths in the repo
- `list` — List files in a revision
- `search` — Search for content in files
- `show` — Print contents of files in a revision
- `track` — Start tracking specified paths in the working copy
- `untrack` — Stop tracking specified paths in the working copy

## `jj file annotate`

Show the source change for each line of the target file.

Annotates a revision line by line. Each line includes the source change that introduced the associated line. A path to the desired file must be provided.

Usage: `jj file annotate [OPTIONS] <PATH>`

###### Arguments:

- `<PATH>` — the file to annotate

###### Options:

- `-r`, `--revision <REVSET>` — an optional revision to start at

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

  All 0-argument methods of the [`AnnotationLine` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

  If not specified, this defaults to the `templates.file_annotate` setting.

## `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> <FILESETS>...`

###### Arguments:

- `<MODE>`

  Possible values:

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

- `<FILESETS>` — Paths to change the executable bit for

###### Options:

- `-r`, `--revision <REVSET>` — The revision to update

  Default value: `@`

## `jj file list`

List files in a revision

Usage: `jj file list [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Only list files matching these prefixes (instead of all files)

###### Options:

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

  Default value: `@`

- `-T`, `--template <TEMPLATE>` — Render each file entry using the given template

  All 0-argument methods of the [`TreeEntry` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

## `jj file search`

Search for content in files

Lists files containing the specified pattern.

This is an early version of the command. It only supports glob matching for now, it doesn't search files concurrently, and it doesn't indicate where in the file the match was found.

Usage: `jj file search [OPTIONS] --pattern <PATTERN> [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Only search files matching these prefixes (instead of all files)

###### Options:

- `-r`, `--revision <REVSET>` — The revision to search files in

  Default value: `@`

- `-p`, `--pattern <PATTERN>` — The pattern to search for in a single line

  It is a string pattern syntax like `kind:pattern`. The kind defaults to regex when omitted.

  If it is a glob pattern, the whole line must match the pattern, so you may want to pass something like `--pattern 'glob:*foo*'`.

## `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] <FILESETS>...`

###### Arguments:

- `<FILESETS>` — Paths to print

###### Options:

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

  Default value: `@`

- `-T`, `--template <TEMPLATE>` — Render each file metadata using the given template

  All 0-argument methods of the [`TreeEntry` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

  If not specified, this defaults to the `templates.file_show` setting.

## `jj file track`

Start tracking specified paths in the working copy

Without arguments, all paths that are not ignored will be tracked.

By default, new files in the working copy are automatically tracked, so this command has no effect. You can configure which paths to automatically track by setting `snapshot.auto-track` (e.g. to `"none()"` or `"glob:**/*.rs"`). Files that don't match the pattern can be manually tracked using this command. The default pattern is `all()`.

Usage: `jj file track [OPTIONS] <FILESETS>...`

###### Arguments:

- `<FILESETS>` — Paths to track

###### Options:

- `--include-ignored` — Track paths even if they're ignored or too large

  By default, `jj file track` will not track files that are ignored by .gitignore or exceed the maximum file size. This flag overrides those restrictions, explicitly tracking the specified paths.

## `jj file untrack`

Stop tracking specified paths in the working copy

Usage: `jj file untrack <FILESETS>...`

###### Arguments:

- `<FILESETS>` — Paths to untrack. They must already be ignored.

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

## `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 modification made by `jj fix` can be reviewed by `jj op show -p`.

### How it works

The changed files in the given revisions will be updated with any fixes determined by passing their file content through any external tools the user has configured for those files. Descendants will also be updated by passing their versions of the same files through the same tools, which will ensure that the fixes are not lost. This 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.

### Deduplication

When fixing multiple commits, if the same file content appears at the same path in different commits, the tool is run only once and the result is reused. This means that tools used with `jj fix` must produce deterministic output.

### Configuration

See `jj help -k config` chapter `Code formatting and other file content transformations` to understand how to configure your tools.

### Execution Example

Let's consider the following configuration is set. We have two code formatters (`clang-format` and `black`), which apply to three different file extensions (`.cc`, `.h`, and `.py`):

    [fix.tools.clang-format]
    command = ["/usr/bin/clang-format", "--assume-filename=$path"]
    patterns = ["glob:'**/*.cc'",
                "glob:'**/*.h'"]

    [fix.tools.black]
    command = ["/usr/bin/black", "-", "--stdin-filename=$path"]
    patterns = ["glob:'**/*.py'"]

Now, let's see what would happen to the following history, when executing `jj fix`.

    C (mutable)
    |  Modifies file: foo.py
    |
    B @ (working copy - mutable)
    |  Modifies file: README.md
    |
    A (mutable)
    |  Modifies files: src/bar.cc and src/bar.h
    |
    X (immutable)

By default, `jj fix` will modify revisions that matches the revset `reachable(@, mutable())` (see `jj help -k revsets`) which corresponds to the revisions `A`, `B` and `C` here.

The following operations will then happen:

- For revision `A`, content from this revision for files `src/bar.cc` and `src/bar.h` will each be provided to `clang-format` and the result output will be used to recreate revision `A` which we will call `A'`. All other files are untouched.
- For revision `B`, same thing happen for files `src/bar.cc` and `src/bar.h` Their content from revision `B` will go through `clang-format`. The file `README.md` as any other files, are untouched as no pattern matches it. We obtain revision `B'`.
- For revision `C`, `src/bar.cc` and `src/bar.h` goes through `clang-format` and file `foo.py` is fixed using `black`. Any other file is untouched. We obtain revision `C'`.

    C (mutable)                    /-> C'
    |  src/bar.cc -> clang-format -|   |
    |  src/bar.h --> clang-format -|   |
    |  foo.py -----> black --------|   |
    |  * --------------------------/   |
    |                                  |
    B @ (working copy - mutable)   /-> B' @
    |  src/bar.cc -> clang-format -|   |
    |  src/bar.h --> clang-format -|   |
    |  * --------------------------|   |
    |                                  |
    A (mutable)                    /-> A'
    |  src/bar.cc -> clang-format -|   |
    |  src/bar.h --> clang-format -|   |
    |  * --------------------------/   |
    |                                  |
    X (immutable)                      X

The revisions are now all correctly formatted according to the configuration.

Usage: `jj fix [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Fix only these paths

###### Options:

- `-s`, `--source <REVSETS>` — 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
- `--include-unchanged-files` — Fix unchanged files in addition to changed ones. If no paths are specified, all files in the repo will be fixed

- `-a`, `--all-lines` — Format all lines instead of only modified lines.

  If the formatter doesn't support formatting only modified lines, then this option has no effect since the formatter always formats all lines.

## `jj gerrit`

Interact with Gerrit Code Review

Usage: `jj gerrit <COMMAND>`

###### Subcommands:

- `upload` — Upload changes to Gerrit for code review, or update existing changes

## `jj gerrit upload`

Upload changes to Gerrit for code review, or update existing changes.

Uploading in a set of revisions to Gerrit creates a single "change" for each revision included in the revset. These changes are then available for review on your Gerrit instance.

Note: The Gerrit commit Id may not match that of your local commit Id, since we add a `Change-Id` footer to the commit message if one does not already exist. This ID is based off the jj Change-Id, but is not the same.

If a change already exists for a given revision (i.e. it contains the same `Change-Id`), this command will update the contents of the existing change to match.

Note: this command takes 1-or-more revsets arguments, each of which can resolve to multiple revisions; so you may post trees or ranges of commits to Gerrit for review all at once.

Usage: `jj gerrit upload [OPTIONS]`

###### Options:

- `-r`, `--revision <REVSETS>` — The revset, selecting which revisions are sent in to Gerrit

  This can be any arbitrary set of commits. Note that when you push a commit at the head of a stack, all ancestors are pushed too. This means that `jj gerrit upload -r foo` is equivalent to `jj gerrit upload -r 'mutable()::foo`.

  If this is not provided, it will check whether @ has a description. * If it does, it will upload @ * Otherwise, it will upload @-

- `-b`, `--remote-branch <REMOTE_BRANCH>` — The location where your changes are intended to land

  This should be a branch on the remote. Can be configured with the `gerrit.default-remote-branch` repository option.

- `--remote <REMOTE>` — The Gerrit remote to push to

  Can be configured with the `gerrit.default-remote` repository option as well. This is typically a full SSH URL for your Gerrit instance.

- `-n`, `--dry-run` — Do not actually push the changes to Gerrit

- `--reviewer <REVIEWER>` — Add these emails as a reviewer (can be repeated)
- `--cc <CC>` — CC these emails on the change (can be repeated)

- `-l`, `--label <LABEL>` — Add the following labels configured by Gerrit (can be repeated)

  Gerrit silently ignores labels not present on your gerrit host. Defaults to +1 if no value is set. Eg. --label=Commit-Queue will set the Commit-Queue label to +1. Eg. --label=Commit-Queue+2 will set it to +2.

- `--topic <TOPIC>` — Applies a topic to the change

  See https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics. Changes can be grouped by topic, and Gerrit can be configured to submit all changes in a topic together in a single click.

- `--hashtag <HASHTAG>` — Applies a hashtag to the change (can be repeated)

  See https://gerrit-review.googlesource.com/Documentation/intro-user.html#hashtags. Hashtags are freeform strings associated with a change, like on social media platforms. Similar to topics, hashtags can be used to group related changes together, and to search using the hashtag: operator. Unlike topics, a change can have multiple hashtags, and they are only used for informational grouping. Changes with the same hashtags are not necessarily submitted together.

- `-m`, `--message <MESSAGE>` — A patch set description for the new patch set

- `--edit` — Push the change as a change edit

  To push a change edit the underlying change need to already exist on the gerrit server. Change edits don't immediately create a new patchset, but need to be published from the web UI first. There can only be one edit for each change. Pushing a new change edit will replace the previous one.

- `--wip` — Marks the change as WIP (work in progress)

  See https://gerrit-review.googlesource.com/Documentation/intro-user.html#wip.

- `--ready` — Unmarks the change as WIP (work in progress)

- `--private` — Marks the change as private

  See https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes.

- `--remove-private` — Unmarks the change as private

- `--publish-comments` — Publishes any draft comments for the given change

- `--no-publish-comments` — Disables publishing of any draft comments for the given change

  This is only useful if the user has configured Gerrit to publish comments by default.

- `--notify <NOTIFY>` — Who to email notifications to (defaults to all)

  Possible values:

  - `none`: No emails
  - `owner`: Only the change owner is notified
  - `owner-reviewers`: Only the change owner and reviewers will be notified
  - `all`: All relevant users, including owner, reviewers, cc'd, users that have starred the change, and users who have configured a watch on files in the change

- `--submit` — Directly submit the changes, bypassing code review

- `--skip-validation` — When --submit is provided, skip performing validations
- `--merged` — Create a new change, even if the change has already been merged
- `--ignore-attention-set` — Do not modify the attention set upon uploading
- `--deadline <DEADLINE>` — The deadline after which the push should be aborted

- `--custom <CUSTOM>` — Send the following custom keyed values to Gerrit (can be repeated)

  See https://gerrit-review.googlesource.com/Documentation/user-upload.html#custom_keyed_values

- `--trace <TRACE>` — For debugging Gerrit

  See https://gerrit-review.googlesource.com/Documentation/user-upload.html#trace

## `jj git`

Commands for working with Git remotes and the underlying Git repo

See this comparison, including a table of commands.

Usage: `jj git <COMMAND>`

###### Subcommands:

- `clone` — Create a new repo backed by a clone of a Git repo
- `colocation` — Manage Jujutsu repository colocation with Git
- `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
- `root` — Show the underlying Git directory of a repository using the Git backend

## `jj git clone`

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

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

###### Arguments:

- `<SOURCE>` — URL or path of the Git repo to clone

  Local path will be resolved to absolute form.

- `<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:

- `--remote <REMOTE_NAME>` — Name of the newly created remote

  Default value: `origin`

- `--colocate` — Colocate the Jujutsu repo with the git repo

  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.

  The repository will contain a `.git` dir in the top-level. Regular Git tools will be able to operate on the repo.

  This is the default, and this option has no effect, unless the git.colocate config is set to `false`.

- `--no-colocate` — Disable colocation of the Jujutsu repo with the git repo

  Prevent Git tools that are unaware of `jj` and regular Git commands from operating on the repo. The Git repository that stores most of the repo data will be hidden inside a sub-directory of the `.jj` directory.

  See colocation docs for some minor advantages of non-colocated workspaces.

- `--depth <DEPTH>` — Create a shallow clone of the given depth

- `--fetch-tags <FETCH_TAGS>` — Configure when to fetch tags

  Unless otherwise specified, the initial clone will fetch all tags, while all subsequent fetches will only fetch included tags.

  Possible values:

  - `all`: Always fetch all tags
  - `included`: Only fetch tags that point to objects that are already being transmitted
  - `none`: Do not fetch any tags

- `-b`, `--branch <BRANCH>` — Name of the branch to fetch and use as the parent of the working-copy change (can be repeated)

  If not present, all branches are fetched and the repository's default branch is used as parent of the working-copy change.

  By default, the specified pattern matches branch names with glob syntax, but only `*` is expanded. Other wildcard characters such as `?` are not supported. Patterns can be repeated or combined with logical operators to specify multiple branches, but only union and negative intersection are supported. If there are multiple matching branches, the first exact branch name is used as the working-copy parent.

  Examples: `push-*`, `(push-* | foo/*) ~ foo/unwanted`

## `jj git colocation`

Manage Jujutsu repository colocation with Git

Usage: `jj git colocation <COMMAND>`

###### Subcommands:

- `disable` — Convert into a non-colocated Jujutsu/Git repository
- `enable` — Convert into a colocated Jujutsu/Git repository
- `status` — Show the current colocation status

## `jj git colocation disable`

Convert into a non-colocated Jujutsu/Git repository

This moves the Git repository that is at the root of the Jujutsu workspace into the .jj directory. Once this is done you will no longer be able to use Git commands directly in the Jujutsu workspace.

Usage: `jj git colocation disable`

## `jj git colocation enable`

Convert into a colocated Jujutsu/Git repository

This moves the underlying Git repository that is found inside the .jj directory to the root of the Jujutsu workspace. This allows you to use Git commands directly in the Jujutsu workspace.

Usage: `jj git colocation enable`

## `jj git colocation status`

Show the current colocation status

Usage: `jj git colocation status`

## `jj git export`

Update the underlying Git repo with changes made in the repo

There is no need to run this command if you're in colocated workspace because the export happens automatically there.

Usage: `jj git export`

## `jj git fetch`

Fetch from a Git remote

If no remotes are specified, fetches the remotes specified by the `git.fetch` setting. If that is not configured and there are multiple remotes, the remote named "origin" will be used.

If no branches nor tags are specified, fetches bookmarks and tags specified by the `remotes.<name>.fetch-bookmarks`/`fetch-tags` settings. If `remotes.<name>.fetch-bookmarks` is not configured, the default fetch refspecs for the selected remotes are read from the Git configuration.

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>` — Name of the branch to fetch (can be repeated)

  By default, the specified pattern matches branch names with glob syntax, but only `*` is expanded. Other wildcard characters such as `?` are not supported. Patterns can be repeated or combined with logical operators to specify multiple branches, but only union and negative intersection are supported.

  Examples: `push-*`, `(push-* | foo/*) ~ foo/unwanted`

- `--tracked` — Fetch only tracked bookmarks

  This fetches only bookmarks that are already tracked from the specified remote(s).

- `--remote <REMOTE>` — The remote to fetch from (only named remotes are supported, can be repeated)

  By default, the specified pattern matches remote names with glob syntax, e.g. `--remote '*'`. You can also use other string pattern syntax.

- `--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.

There is no need to run this command if you're in colocated workspace because the import happens automatically there.

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` — Colocate the Jujutsu repo with the git repo

  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.

  The repository will contain a `.git` dir in the top-level. Regular Git tools will be able to operate on the repo.

  This is the default, and this option has no effect, unless the git.colocate config is set to `false`.

  This option is mutually exclusive with `--git-repo`.

- `--no-colocate` — Disable colocation of the Jujutsu repo with the git repo

  Prevent Git tools that are unaware of `jj` and regular Git commands from operating on the repo. The Git repository that stores most of the repo data will be hidden inside a sub-directory of the `.jj` directory.

  See colocation docs for some minor advantages of non-colocated workspaces.

- `--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 colocated workspace.

  This option is mutually exclusive with `--colocate`, and so if passed, turns colocation off.

## `jj git push`

Push to a Git remote

By default, pushes tracking bookmarks pointing to `remote_bookmarks(remote=<remote>)..@`. Use `--bookmark` to push specific bookmarks. Use `--all` to push all bookmarks. Use `--change` to generate bookmark names based on the change IDs of specific commits.

When pushing a bookmark, the command pushes all commits in the range from the remote's current position up to and including the bookmark's target commit. Any descendant commits beyond the bookmark are not pushed.

If the local bookmark has changed from the last fetch, push will update the remote bookmark to the new position after passing safety checks. This is similar to `git push --force-with-lease` - the remote is updated only if its current state matches what Jujutsu last fetched.

Unlike in Git, the remote to push to is not derived from the tracked remote bookmarks. Use `--remote` to select the remote Git repository by name. There is no option to push to multiple remotes.

Before the command actually moves, creates, or deletes a remote bookmark, 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 bookmark conflicts.

Usage: `jj git push [OPTIONS]`

###### Options:

- `--remote <REMOTE>` — The remote to push to (only named remotes are supported)

  This defaults to the `git.push` setting. If that is not configured, and if there are multiple remotes, the remote named "origin" will be used.

- `-b`, `--bookmark <BOOKMARK>` — Push only this bookmark, or bookmarks matching a pattern (can be repeated)

  If a bookmark isn't tracking anything yet, the remote bookmark will be tracked automatically.

  By default, the specified pattern matches bookmark names with glob syntax. You can also use other string pattern syntax.

- `--all` — Push all bookmarks (including new bookmarks)

- `--tracked` — Push all tracked bookmarks

  This usually means that the bookmark was already pushed to or fetched from the relevant remote.

- `--deleted` — Push all deleted bookmarks

  Only tracked bookmarks can be successfully deleted on the remote. A warning will be printed if any untracked bookmarks on the remote correspond to missing local bookmarks.

- `--allow-empty-description` — Allow pushing commits with empty descriptions

- `--allow-private` — Allow pushing commits that are private

  The set of private commits can be configured by the `git.private-commits` setting. The default is `none()`, meaning all commits are eligible to be pushed.

- `-r`, `--revision <REVSETS>` — Push bookmarks pointing to these commits (can be repeated)

- `-c`, `--change <REVSETS>` — Push this commit by creating a bookmark (can be repeated)

  The created bookmark will be tracked automatically. Use the `templates.git_push_bookmark` setting to customize the generated bookmark name. The default is `"push-" ++ change_id.short()`.

- `--named <NAME=REVISION>` — Specify a new bookmark name and a revision to push under that name, e.g. '--named myfeature=@'

  Automatically tracks the bookmark if it is new.

- `--dry-run` — Only display what will change on the remote

- `-o`, `--option <OPTION>` — Git push options

## `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 bookmarks
- `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 [OPTIONS] <REMOTE> <URL>`

###### Arguments:

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

- `<URL>` — The remote's URL or path

  Local path will be resolved to absolute form.

###### Options:

- `--fetch-tags <FETCH_TAGS>` — Configure when to fetch tags

  Default value: `included`

  Possible values:

  - `all`: Always fetch all tags
  - `included`: Only fetch tags that point to objects that are already being transmitted
  - `none`: Do not fetch any tags

- `--push-url <PUSH_URL>` — The URL used for push

  Local path will be resolved to absolute form

## `jj git remote list`

List Git remotes

Usage: `jj git remote list`

## `jj git remote remove`

Remove a Git remote and forget its bookmarks

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 [OPTIONS] <REMOTE> [URL]`

###### Arguments:

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

- `<URL>` — The URL or path to fetch from

  This is a short form, equivalent to using the explicit --fetch.

  Local path will be resolved to absolute form.

###### Options:

- `--push <PUSH>` — The URL or path to push to

  Local path will be resolved to absolute form.

- `--fetch <FETCH>` — The URL or path to fetch from

  Local path will be resolved to absolute form.

## `jj git root`

Show the underlying Git directory of a repository using the Git backend

Usage: `jj git root`

## `jj help`

Print this message or the help of the given subcommand(s)

Usage: `jj help [OPTIONS] [COMMAND]...`

###### Arguments:

- `<COMMAND>` — Print help for the subcommand(s)

###### Options:

- `-k`, `--keyword <KEYWORD>` — Show help for keywords instead of commands

  Possible values:

  - `bookmarks`: Named pointers to revisions (similar to Git's branches)
  - `config`: How and where to set configuration options
  - `filesets`: A functional language for selecting a set of files
  - `glossary`: Definitions of various terms
  - `revsets`: A functional language for selecting a set of revision
  - `templates`: A functional language to customize command output
  - `tutorial`: Show a tutorial to get started with jj

## `jj interdiff`

Show differences between the diffs of two revisions

This is like running `jj diff -r` on each change, then comparing those results. It answers: "How do the modifications introduced by revision A differ from the modifications introduced by revision B?"

For example, if two changes both add a feature but implement it differently, `jj interdiff --from @- --to other` shows what one implementation adds or removes that the other doesn't.

A common use of this command is to compare how a change has changed since the last push to a remote:

`sh $ jj interdiff --from push-xyz@origin --to push-xyz`

This command is different from `jj diff --from A --to B`, which compares file contents directly. `interdiff` compares what the changes do in terms of their patches, rather than their file contents. This makes a difference when the two revisions have different parents: `jj diff --from A --to B` will include the changes between their parents while `jj interdiff --from A --to B` will not.

Technically, this works by rebasing `--from` onto `--to`'s parents and comparing the result to `--to`.

To see the changes throughout the whole evolution of a change instead of between just two revisions, use `jj evolog -p` instead.

Usage: `jj interdiff [OPTIONS] <--from <REVSET>|--to <REVSET>> [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Restrict the diff to these paths

###### Options:

- `-f`, `--from <REVSET>` — The first revision to compare (default: @)
- `-t`, `--to <REVSET>` — The second revision to compare (default: @)
- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `-w`, `--ignore-all-space` — Ignore whitespace when comparing lines
- `-b`, `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

## `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. Use `jj log -r ::` to see all revisions. See [`jj help -k revsets`] for information about the syntax.

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

The working-copy commit is indicated by a `@` symbol in the graph. Immutable revisions have a `◆` symbol. Other commits have a `○` symbol. All of these symbols can be customized.

Usage: `jj log [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Show revisions modifying the given paths

###### Options:

- `-r`, `--revision <REVSETS>` — Which revisions to show

  If no paths nor revisions are specified, this defaults to the `revsets.log` setting.

- `-n`, `--limit <LIMIT>` — Limit number of revisions to show

  Applied after revisions are filtered and reordered topologically, but before being reversed.

- `--reversed` — Show revisions in the opposite order (older revisions first)

- `-G`, `--no-graph` — Don't show the graph, show a flat list of revisions

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

  Run `jj log -T` to list the built-in templates.

  You can also specify arbitrary template expressions using the built-in keywords. See [`jj help -k templates`] for more information.

  If not specified, this defaults to the `templates.log` setting.

- `-p`, `--patch` — Show patch

- `--count` — Print the number of commits instead of showing them
- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--ignore-all-space` — Ignore whitespace when comparing lines
- `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

## `jj metaedit`

Modify the metadata of a revision without changing its content

Whenever any metadata is updated, the committer name, email, and timestamp are also updated for all rebased commits. The name and email may come from the `JJ_USER` and `JJ_EMAIL` environment variables, as well as by passing `--config user.name` and `--config user.email`.

Usage: `jj metaedit [OPTIONS] [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revision(s) to modify (default: @) [aliases: -r]

###### Options:

- `--update-change-id` — Generate a new change-id

  This generates a new change-id for the revision.

- `-m`, `--message <MESSAGE>` — Update the change description

  This updates the change description, without opening the editor.

  Use `jj describe` if you want to use an editor.

- `--update-author-timestamp` — Update the author timestamp

  This updates the author date to the current time, without modifying the author.

- `--update-author` — Update the author to the configured user

  This updates the author name and email. The author timestamp is not modified – use --update-author-timestamp to update the author 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 metaedit --update-author

- `--author <AUTHOR>` — Set author to the provided string

  This changes author name and email while retaining author timestamp for non-discardable commits.

  `shell $ jj metaedit --author "Foo Bar <foo@bar.com>"`

- `--author-timestamp <AUTHOR_TIMESTAMP>` — Set the author date to the given date

  The date can either be human readable (RFC2822, eg 'Sun, 23 Jan 2000 01:23:45 PST') or a time stamp (RFC3339, eg '2000-01-23T01:23:45-08:00').

- `--force-rewrite` — Rewrite the commit, even if no other metadata changed

  This updates the committer timestamp to the current time, as well as the committer name and email.

  Even if this option is not passed, the committer name, email, and timestamp will be updated if other metadata is updated. This option just forces every commit to be rewritten whether or not there are other changes.

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

  $ JJ_USER='Foo Bar' JJ_EMAIL=foo@bar.com jj metaedit --force-rewrite

## `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 working copy and the `main` bookmark as parents.

Usage: `jj new [OPTIONS] [REVSETS]...`

###### Arguments:

- `<REVSETS>` — Parent(s) of the new change [default: @] [aliases: -o, -r]

###### Options:

- `-m`, `--message <MESSAGE>` — The change description to use
- `--no-edit` — Do not edit the newly created change

- `-A`, `--insert-after <REVSETS>` [alias: `after`] — Insert the new change after the given commit(s)

  Example: `jj new --insert-after A` creates a new change between `A` and its children:

                      B   C
                       \ /
          B   C   =>    @
           \ /          |
            A           A

  Specifying `--insert-after` multiple times will relocate all children of the given commits.

  Example: `jj new --insert-after A --insert-after X` creates a change with `A` and `X` as parents, and rebases all children on top of the new change:

                      B   Y
                       \ /
          B  Y    =>    @
          |  |         / \
          A  X        A   X

- `-B`, `--insert-before <REVSETS>` [alias: `before`] — Insert the new change before the given commit(s)

  Example: `jj new --insert-before C` creates a new change between `C` and its parents:

                         C
                         |
            C     =>     @
           / \          / \
          A   B        A   B

  `--insert-after` and `--insert-before` can be combined.

  Example: `jj new --insert-after A --insert-before D`:

          D            D
          |           / \
          C          |   C
          |    =>    @   |
          B          |   B
          |           \ /
          A            A

  Similar to `--insert-after`, you can specify `--insert-before` multiple times.

## `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:

    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.

    D        D
    |        |
    C        C
    |        |
    B   =>   @
    |        |
    @        A

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`)

  Takes precedence over config in `ui.movement.edit`; i.e. will negate `ui.movement.edit = false`

- `-n`, `--no-edit` — The inverse of `--edit`

  Takes precedence over config in `ui.movement.edit`; i.e. will negate `ui.movement.edit = true`

- `--conflict` — Jump to the next conflicted descendant

## `jj operation`

Commands for working with the operation log

See the operation log documentation for more information.

Usage: `jj operation <COMMAND>`

Command Alias: `op`

###### Subcommands:

- `abandon` — Abandon operation history
- `diff` — Compare changes to the repository between two operations
- `integrate` — Make an operation part of the operation log
- `log` — Show the operation log
- `restore` — Create a new operation that restores the repo to an earlier state
- `revert` — Create a new operation that reverts an earlier operation
- `show` — Show changes to the repository in an 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>..@-`.

Previous versions of a change (or predecessors) are also discarded if they become unreachable from the operation history. 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 diff`

Compare changes to the repository between two operations

Usage: `jj operation diff [OPTIONS]`

###### Options:

- `--operation <OPERATION>` [alias: `op`] — Show repository changes in this operation, compared to its parent
- `-f`, `--from <FROM>` — Show repository changes from this operation
- `-t`, `--to <TO>` — Show repository changes to this operation
- `-G`, `--no-graph` — Don't show the graph, show a flat list of modified changes

- `-p`, `--patch` — Show patch of modifications to changes

  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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--ignore-all-space` — Ignore whitespace when comparing lines
- `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

- `--show-changes-in <REVSETS>` — Show only changed revisions matching the given revset expression

  If no revisions are specified, this defaults to the `revsets.op-diff-changes-in` setting.

## `jj operation integrate`

Make an operation part of the operation log

By default, operations are automatically integrated into the operation log, but `--no-integrate-operation` or internal errors may cause that to not happen. This command can then be used for making such operations part of the operation log.

Running this command on an operation that is already in the operation log (`jj op log`) has no effect.

Usage: `jj operation integrate <OPERATION>`

###### Arguments:

- `<OPERATION>` — The operation to integrate

## `jj operation log`

Show the operation log

Like other commands, `jj op log` snapshots the current working-copy changes and reconciles divergent operations. Use `--at-op=@ --ignore-working-copy` to inspect the current state without mutation.

Usage: `jj operation log [OPTIONS]`

###### Options:

- `-n`, `--limit <LIMIT>` — Limit number of operations to show

  Applied after operations are reordered topologically, but before being reversed.

- `--reversed` — Show operations in the opposite order (older operations first)

- `-G`, `--no-graph` — Don't show the graph, show a flat list of operations

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

  You can specify arbitrary template expressions using the built-in keywords. See [`jj help -k templates`] for more information.

- `-d`, `--op-diff` — Show changes to the repository at each operation

- `-p`, `--patch` — Show patch of modifications to changes (implies --op-diff)

  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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--ignore-all-space` — Ignore whitespace when comparing lines
- `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

- `--show-changes-in <REVSETS>` — Show only changed revisions matching the given revset expression

  If no revisions are specified, this defaults to the `revsets.op-diff-changes-in` setting.

## `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 bookmarks
  - `remote-tracking`: The remote-tracking bookmarks. Do not restore these if you'd like to push after the undo

## `jj operation revert`

Create a new operation that reverts an earlier operation

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

Usage: `jj operation revert [OPTIONS] [OPERATION]`

###### Arguments:

- `<OPERATION>` — The operation to revert

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

  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 bookmarks
  - `remote-tracking`: The remote-tracking bookmarks. Do not restore these if you'd like to push after the undo

## `jj operation show`

Show changes to the repository in an operation

Usage: `jj operation show [OPTIONS] [OPERATION]`

###### Arguments:

- `<OPERATION>` — Show repository changes in this operation, compared to its parent(s)

  Default value: `@`

###### Options:

- `-G`, `--no-graph` — Don't show the graph, show a flat list of modified changes

- `-T`, `--template <TEMPLATE>` — Render the operation using the given template

  You can specify arbitrary template expressions using the built-in keywords. See [`jj help -k templates`] for more information.

- `-p`, `--patch` — Show patch of modifications to changes

  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.

- `--no-op-diff` — Do not show operation diff

- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--ignore-all-space` — Ignore whitespace when comparing lines
- `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

- `--show-changes-in <REVSETS>` — Show only changed revisions matching the given revset expression

  If no revisions are specified, this defaults to the `revsets.op-diff-changes-in` setting.

## `jj parallelize`

Parallelize revisions by making them siblings

Running `jj parallelize 1::2` will transform the history like this:

    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 [REVSETS]...`

###### Arguments:

- `<REVSETS>` — The revisions to parallelize [aliases: -r]

## `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:

    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.

    D @      D
    |/       |
    C   =>   @
    |        |
    B        B
    |        |
    A        A

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

  Takes precedence over config in `ui.movement.edit`; i.e. will negate `ui.movement.edit = false`

- `-n`, `--no-edit` — The inverse of `--edit`

  Takes precedence over config in `ui.movement.edit`; i.e. will negate `ui.movement.edit = true`

- `--conflict` — Jump to the previous conflicted ancestor

## `jj rebase`

Move revisions to different parent(s)

This command moves revisions to different parent(s) while preserving the changes (diff) in the revisions.

There are three different ways of specifying which revisions to rebase:

- `--source/-s` to rebase a revision and its descendants
- `--branch/-b` to rebase a whole branch, relative to the destination
- `--revisions/-r` to rebase the specified revisions without their descendants

If no option is specified, it defaults to `-b @`.

There are three different ways of specifying where the revisions should be rebased to:

- `--onto/-o` to rebase the revisions onto the specified targets
- `--insert-after/-A` to rebase the revisions onto the specified targets and to rebase the targets' descendants onto the rebased revisions
- `--insert-before/-B` to rebase the revisions onto the specified targets' parents and to rebase the targets and their descendants onto the rebased revisions

See the sections below for details about the different ways of specifying which revisions to rebase where.

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

### Specifying which revisions to rebase

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

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

Each revision passed to `-s` will become a direct child of the destination, so if you instead run `jj rebase -s M -s N -o O` (or `jj rebase -s 'M|N' -o O`) in the example above, then N' would instead be a direct child of O.

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

- the specified revision and ancestors that are not also ancestors of the destination
- all descendants of those revisions

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

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

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

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

Multiple revisions can be specified, and any dependencies (graph edges) within the set will be preserved. For example, `jj rebase -r 'K|N' -o O` would transform your history like this:

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

`jj rebase -s X` is similar to `jj rebase -r X::` and will behave the same if X is a single revision. However, if X is a set of multiple revisions, or if you passed multiple `-s` arguments, then `jj rebase -s` will make each of the specified revisions an immediate child of the destination, while `jj rebase -r` will preserve dependencies within the set.

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

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

### Specifying where to rebase the revisions

With `--onto/-o`, the command rebases the selected revisions onto the targets. Existing descendants of the targets will not be affected. See the section above for examples.

With `--insert-after/-A`, the selected revisions will be inserted after the targets. This is similar to `-o`, but if the targets have any existing descendants, then those will be rebased onto the rebased selected revisions.

For example, `jj rebase -r K -A L` will rewrite history like this:

    N           N'
    |           |
    | M         | M'
    |/          |/
    L      =>   K'
    |           |
    | K         L
    |/          |
    J           J

The `-A` (and `-B`) argument can also be used for reordering revisions. For example, `jj rebase -r M -A J` will rewrite history like this:

    M          L'
    |          |
    L          K'
    |     =>   |
    K          M'
    |          |
    J          J

With `--insert-before/-B`, the selected revisions will be inserted before the targets. This is achieved by rebasing the selected revisions onto the target revisions' parents, and then rebasing the target revisions and their descendants onto the rebased revisions.

For example, `jj rebase -r K -B L` will rewrite history like this:

    N           N'
    |           |
    | M         | M'
    |/          |/
    L     =>    L'
    |           |
    | K         K'
    |/          |
    J           J

The `-A` and `-B` arguments can also be combined, which can be useful around merges. For example, you can use `jj rebase -r K -A J -B M` to create a new merge (but `jj rebase -r M -o L -o K` might be simpler in this particular case):

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

To insert a commit inside an existing merge with `jj rebase -r O -A K -B M`:

    O           N'
    |           |\
    N           | M'
    |\          | |\
    | M         | O'|
    | |    =>   |/ /
    | L         | L
    | |         | |
    K |         K |
    |/          |/
    J           J

Usage: `jj rebase [OPTIONS] <--onto <REVSETS>|--insert-after <REVSETS>|--insert-before <REVSETS>>`

###### Options:

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

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

  If none of `-b`, `-s`, or `-r` is provided, then the default is `-b @`.

- `-s`, `--source <REVSETS>` — 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`, `--revision <REVSETS>` — 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 @`.

- `-o`, `--onto <REVSETS>` — The revision(s) to rebase onto (can be repeated to create a merge commit)

- `-A`, `--insert-after <REVSETS>` [alias: `after`] — The revision(s) to insert after (can be repeated to create a merge commit)
- `-B`, `--insert-before <REVSETS>` [alias: `before`] — The revision(s) to insert before (can be repeated to create a merge commit)
- `--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

- `--keep-divergent` — Keep divergent commits while rebasing

  Without this flag, divergent commits are abandoned while rebasing if another commit with the same change ID is already present in the destination with identical changes.

- `--simplify-parents` — Simplify parents of rebased commits, like `jj simplify-parents`, while rebasing them. Any parents that are ancestors of other parents will be removed

## `jj redo`

Redo the most recently undone operation

This is the natural counterpart of `jj undo`. Repeated invocations of `jj undo` and `jj redo` act similarly to Undo/Redo commands in a text editor.

Use `jj op log` to visualize the log of past operations, including a detailed description of any past undo/redo operations. See also `jj op restore` to explicitly restore an older operation by its id (available in the operation log).

Usage: `jj redo`

## `jj resolve`

Resolve conflicted files 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. External merge tools will be invoked for each conflicted file one-by-one until all conflicts are resolved. To stop resolving conflicts, exit the merge tool without making any changes.

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] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Only resolve conflicts in these paths. You can use the `--list` argument to find paths to use here

###### Options:

- `-r`, `--revision <REVSET>`

  Default value: `@`

- `-l`, `--list` — Instead of resolving conflicts, list all the conflicts

- `--tool <NAME>` — Specify 3-way merge tool to be used

  The built-in merge tools `:ours` and `:theirs` can be used to choose side #1 and side #2 of the conflict respectively.

## `jj restore`

Restore paths from another revision

That means that the paths get the same content in the destination (`--into`) 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 `--into` is specified, the other one defaults to the working copy.

When neither `--from` nor `--into` 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] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Restore only these paths (instead of all paths)

###### Options:

- `-f`, `--from <REVSET>` — Revision to restore from (source)
- `-t`, `--into <REVSET>` [alias: `to`] — Revision to restore into (destination)

- `-c`, `--changes-in <REVSET>` — 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 REVSET`. If `REVSET` only has a single parent, this option is equivalent to `jj restore --into REVSET --from REVSET-`.

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

- `-i`, `--interactive` — Interactively choose which parts to restore

- `--tool <NAME>` — Specify diff editor to be used (implies --interactive)
- `--restore-descendants` — Preserve the content (not the diff) when rebasing descendants

## `jj revert`

Apply the reverse of the given revision(s)

The reverse of each of the given revisions is applied sequentially in reverse topological order at the given location.

The description of the new revisions can be customized with the `templates.revert_description` config variable.

Usage: `jj revert --revision <REVSETS> <--onto <REVSETS>|--insert-after <REVSETS>|--insert-before <REVSETS>>`

###### Options:

- `-r`, `--revision <REVSETS>` — The revision(s) to apply the reverse of
- `-o`, `--onto <REVSETS>` [alias: `destination`] — The revision(s) to apply the reverse changes on top of
- `-A`, `--insert-after <REVSETS>` [alias: `after`] — The revision(s) to insert the reverse changes after (can be repeated to create a merge commit)
- `-B`, `--insert-before <REVSETS>` [alias: `before`] — The revision(s) to insert the reverse changes before (can be repeated to create a merge commit)

## `jj root`

Show the current workspace root directory (shortcut for `jj workspace root`)

Usage: `jj root`

## `jj show`

Show commit description and changes in a revision

Usage: `jj show [OPTIONS] [REVSET]`

###### Arguments:

- `<REVSET>` — Show changes in this revision, compared to its parent(s) [default: @] [aliases: -r]

###### Options:

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

  You can specify arbitrary template expressions using the built-in keywords. See [`jj help -k templates`] for more information.

- `-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

  A builtin format can also be specified as `:<name>`. For example, `--tool=:git` is equivalent to `--git`.

- `--context <CONTEXT>` — Number of lines of context to show

- `--no-patch` — Do not show the patch
- `-w`, `--ignore-all-space` — Ignore whitespace when comparing lines
- `-b`, `--ignore-space-change` — Ignore changes in amount of whitespace when comparing lines

## `jj sign`

Cryptographically sign a revision

This command requires configuring a commit signing backend.

Usage: `jj sign [OPTIONS]`

###### Options:

- `-r`, `--revision <REVSETS>` — What revision(s) to sign

  If no revisions are specified, this defaults to the `revsets.sign` setting.

  Note that revisions are always re-signed.

  While that leads to discomfort for users, which sign with hardware devices, as of now we cannot reliably check if a commit is already signed by the user without creating a signature (see #5786).

- `--key <KEY>` — The key used for signing

## `jj simplify-parents`

Simplify parent edges for the specified revision(s).

Removes all parents of each of the specified revisions that are also indirect ancestors of the same revisions through other parents. This has no effect on any revision's contents, including the working copy.

In other words, for all (A, B, C) where A has (B, C) as parents and C is an ancestor of B, A will be rewritten to have only B as a parent instead of B+C.

Usage: `jj simplify-parents [OPTIONS]`

###### Options:

- `-s`, `--source <REVSETS>` — Simplify specified revision(s) together with their trees of descendants (can be repeated)

- `-r`, `--revision <REVSETS>` — Simplify specified revision(s) (can be repeated)

  If both `--source` and `--revisions` are not provided, this defaults to the `revsets.simplify-parents` setting, or `reachable(@, mutable())` if it is not set.

## `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 commit. Once you close the editor, your revision will be split into two commits.

By default, the selected changes stay in the original commit, and the remaining changes go into a new child commit:

    L                 L'
    |                 |
    K (split)   =>    K" (remaining)
    |                 |
    J                 K' (selected)
                      |
                      J

With `--parallel/-p`, the two parts become sibling commits instead of parent and child:

                      L'
    L                / \
    |               K'  |  (selected)
    K (split)  =>   |   K" (remaining)
    |                \ /
    J                 J

With `-o`, `-A`, or `-B`, the selected changes are extracted into a new commit at the specified location, while the remaining changes stay in place:

    M                 M'
    |                 |
    L                 L'
    |                 |
    K (split)   =>    K' (remaining, stays here)
    |                 |
    J                 J'
                      |
                      K" (selected, inserted before J with -B J)

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 commit will not get a description, and you will be asked for a description only for the first commit.

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

Usage: `jj split [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Files matching any of these filesets are put in the selected changes

###### Options:

- `-i`, `--interactive` — Interactively choose which parts to split

  This is the default if no filesets are provided.

- `--tool <NAME>` — Specify diff editor to be used (implies --interactive)

- `-r`, `--revision <REVSET>` — The revision to split

  Default value: `@`

- `-o`, `--onto <REVSETS>` [alias: `destination`] — The revision(s) to rebase the selected changes onto (can be repeated to create a merge commit)

  Extracts the selected changes into a new commit based on the given revision(s). The remaining changes stay in the original commit's location.

- `-A`, `--insert-after <REVSETS>` [alias: `after`] — The revision(s) to insert after (can be repeated to create a merge commit)

  Extracts the selected changes into a new commit inserted after the given revision(s). The remaining changes stay in the original commit's location.

- `-B`, `--insert-before <REVSETS>` [alias: `before`] — The revision(s) to insert before (can be repeated to create a merge commit)

  Extracts the selected changes into a new commit inserted before the given revision(s). The remaining changes stay in the original commit's location.

- `-m`, `--message <MESSAGE>` — The change description to use for the selected changes (don't open editor)

  Sets the description for the revision containing the selected changes. The other revision will keep its original description, if any.

- `--editor` — Open an editor to edit the change description(s)

  Forces an editor to open when using `--message` to allow the message to be edited afterward.

- `-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

Without any options, moves the changes from the working-copy revision to the parent 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 was abandoned 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.

The name "squash" comes from the idea of combining (squashing) the changes from multiple revisions together.

EXPERIMENTAL FEATURES

An alternative squashing UI is available via the `-o`, `-A`, and `-B` options. Using any of these options creates a new commit. They can be used together with one or more `--from` options (if no `--from` is specified, `--from @` is assumed).

Usage: `jj squash [OPTIONS] [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Move only changes to these paths (instead of all paths)

###### Options:

- `-r`, `--revision <REVSET>` — Revision to squash into its parent (default: @). Incompatible with the experimental `-o`/`-A`/`-B` options
- `-f`, `--from <REVSETS>` — Revision(s) to squash from (default: @)
- `-t`, `--into <REVSET>` [alias: `to`] — Revision to squash into (default: @)
- `-o`, `--onto <REVSETS>` [alias: `destination`] — (Experimental) The revision(s) to use as parent for the new commit (can be repeated to create a merge commit)
- `-A`, `--insert-after <REVSETS>` [alias: `after`] — (Experimental) The revision(s) to insert the new commit after (can be repeated to create a merge commit)
- `-B`, `--insert-before <REVSETS>` [alias: `before`] — (Experimental) The revision(s) to insert the new commit before (can be repeated to create a merge commit)
- `-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)

- `--editor` — Open an editor to edit the change description

  Forces an editor to open when using `--message` to allow the message to be edited afterwards.

- `-i`, `--interactive` — Interactively choose which parts to squash

- `--tool <NAME>` — Specify diff editor to be used (implies --interactive)
- `-k`, `--keep-emptied` — The source revision will not be abandoned

## `jj status`

Show high-level repo status [default alias: st]

This includes:

- The working copy commit and its parents, and a summary of the changes in the working copy (compared to the merged parents)

- Conflicts in the working copy

- Conflicted bookmarks

Note: You can use `jj diff --summary -r <rev>` to see the changed files for a specific revision.

Usage: `jj status [FILESETS]...`

###### Arguments:

- `<FILESETS>` — Restrict the status display to these paths

## `jj tag`

Manage tags

Usage: `jj tag <COMMAND>`

###### Subcommands:

- `delete` — Delete existing tags
- `list` — List tags and their targets
- `set` — Create or update tags

## `jj tag delete`

Delete existing tags

Revisions referred to by the deleted tags are not abandoned.

Usage: `jj tag delete <NAMES>...`

Command Alias: `d`

###### Arguments:

- `<NAMES>` — Tag names to delete

  By default, the specified pattern matches tag names with glob syntax. You can also use other string pattern syntax.

## `jj tag list`

List tags and their targets

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

The `-r` flag combined with revset expressions can be used for filtering. For example:

- `jj tag list -r 'REV::'` shows tags whose targets are descendants of REV (similar to `git tag --contains REV`).

- `jj tag list -r '::REV'` shows tags whose targets are ancestors of REV (similar to `git tag --merged REV`).

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

Command Alias: `l`

###### Arguments:

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

  By default, the specified pattern matches tag names with glob syntax. You can also use other string pattern syntax.

###### Options:

- `-a`, `--all-remotes` — Show all tracked and untracked remote tags including the ones whose targets are synchronized with the local tags
- `-c`, `--conflicted` — Show conflicted tags only

- `-r`, `--revision <REVSETS>` — Show tags whose local targets are in the given revisions

  Note that `-r deleted_tag` will not work since `deleted_tag` wouldn't have a local target.

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

  All 0-argument methods of the [`CommitRef` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

- `--sort <SORT_KEY>` — Sort tags based on the given key (or multiple keys)

  Suffix the key with `-` to sort in descending order of the value (e.g. `--sort name-`). Note that when using multiple keys, the first key is the most significant.

  This defaults to the `ui.tag-list-sort-keys` setting.

  Possible values: `name`, `name-`, `author-name`, `author-name-`, `author-email`, `author-email-`, `author-date`, `author-date-`, `committer-name`, `committer-name-`, `committer-email`, `committer-email-`, `committer-date`, `committer-date-`

## `jj tag set`

Create or update tags

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

Command Alias: `s`

###### Arguments:

- `<NAMES>` — Tag names to create or update

###### Options:

- `-r`, `--revision <REVSET>` [alias: `to`] — Target revision to point to

  Default value: `@`

- `--allow-move` — Allow moving existing tags

## `jj undo`

Undo the last operation

If used once after a normal (non-`undo`) operation, this will undo that last operation by restoring its parent. If `jj undo` is used repeatedly, it will restore increasingly older operations, going further back into the past.

There is also a complementary `jj redo` command that would instead move in the direction of the future after one or more `jj undo`s.

Use `jj op log` to visualize the log of past operations, including a detailed description of any past undo/redo operations. See also `jj op restore` to explicitly restore an older operation by its id (available in the operation log).

Usage: `jj undo`

## `jj unsign`

Drop a cryptographic signature

See also commit signing docs.

Usage: `jj unsign [OPTIONS]`

###### Options:

- `-r`, `--revision <REVSETS>` — What revision(s) to unsign

## `jj util`

Infrequently used commands such as for generating shell completions

Usage: `jj util <COMMAND>`

###### Subcommands:

- `completion` — Print a command-line-completion script
- `config-schema` — Print the JSON schema for the jj TOML config format
- `exec` — Execute an external command via jj
- `gc` — Run backend-dependent garbage collection
- `install-man-pages` — Install Jujutsu's manpages to the provided path
- `markdown-help` — Print the CLI help for all subcommands in Markdown
- `snapshot` — Snapshot the working copy if needed

## `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:

      jj util completion nushell | save -f "completions-jj.nu"
      use "completions-jj.nu" *  # Or `source "completions-jj.nu"`

- Zsh:

      autoload -U compinit
      compinit
      source <(jj util completion zsh)

See the docs on command-line completion for more details.

Usage: `jj util completion <SHELL>`

###### Arguments:

- `<SHELL>`

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

## `jj util config-schema`

Print the JSON schema for the jj TOML config format

Usage: `jj util config-schema`

## `jj util exec`

Execute an external command via jj

This command will have access to the environment variable JJ_WORKSPACE_ROOT.

This is useful for arbitrary aliases.

!! WARNING !!

The following technique just provides a convenient syntax for running arbitrary code on your system. Using it irresponsibly may cause damage ranging from breaking the behavior of `jj undo` to wiping your file system. Exercise the same amount of caution while writing these aliases as you would when typing commands into the terminal!

This feature may be removed or replaced by an embedded scripting language in the future.

Let's assume you have a script called "my-jj-script" in you $PATH and you would like to execute it as "jj my-script". You would add the following line to your configuration file to achieve that:

    [aliases]
    my-script = ["util", "exec", "--", "my-jj-script"]
    #                            ^^^^
    # This makes sure that flags are passed to your script instead of parsed by jj.

If you don't want to manage your script as a separate file, you can even inline it into your config file:

    [aliases]
    my-inline-script = ["util", "exec", "--", "bash", "-c", """
    set -euo pipefail
    echo "Look Ma, everything in one file!"
    echo "args: $@"
    """, ""]
    #    ^^
    # This last empty string will become "$0" in bash, so your actual arguments
    # are all included in "$@" and start at "$1" as expected.

> Note: Shebangs (e.g. `#!/usr/bin/env`) aren't necessary since you're already explicitly passing your script into the right shell.

Usage: `jj util exec <COMMAND> [ARGS]...`

###### Arguments:

- `<COMMAND>` — External command to execute
- `<ARGS>` — Arguments to pass to the external command

## `jj util gc`

Run backend-dependent garbage collection.

To garbage-collect old operations and the commits/objects referenced by them, run `jj op abandon ..<some old operation>` before `jj util gc`.

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 install-man-pages`

Install Jujutsu's manpages to the provided path

Usage: `jj util install-man-pages <PATH>`

###### Arguments:

- `<PATH>` — The path where manpages will installed. An example path might be `/usr/share/man`. The provided path will be appended with `man1`, etc., as appropriate

## `jj util markdown-help`

Print the CLI help for all subcommands in Markdown

Usage: `jj util markdown-help`

## `jj util snapshot`

Snapshot the working copy if needed

Snapshots the working copy and updates the working-copy commit if the working copy has changed since the last snapshot. Since almost every command snapshots the working copy, there is very little reason to run this command as a human; it is mostly meant for scripts.

If you want to see the ID of the current operation after this command, run `jj operation log --limit 1`. However, since that command also snapshots the working copy, there would be no need to run `jj util snapshot` first.

Usage: `jj util snapshot`

## `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
- `rename` — Renames the current workspace
- `root` — Show the workspace root directory
- `update-stale` — Update a workspace that has become stale

## `jj workspace add`

Add a workspace

By default, the new workspace inherits the sparse patterns of the current workspace. You can override this with the `--sparse-patterns` option.

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 <REVSETS>` — 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 ...`.

- `-m`, `--message <MESSAGE>` — The change description to use

- `--sparse-patterns <SPARSE_PATTERNS>` — How to handle sparse patterns when creating a new workspace

  Default value: `copy`

  Possible values:

  - `copy`: Copy all sparse patterns from the current workspace
  - `full`: Include all files in the new workspace
  - `empty`: Clear all files from the workspace (it will be empty)

## `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 [OPTIONS]`

###### Options:

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

  All 0-argument methods of the [`WorkspaceRef` type] are available as keywords in the template expression. See [`jj help -k templates`] for more information.

## `jj workspace rename`

Renames the current workspace

Usage: `jj workspace rename <NEW_WORKSPACE_NAME>`

###### Arguments:

- `<NEW_WORKSPACE_NAME>` — The name of the workspace to update to

## `jj workspace root`

Show the workspace root directory

Usage: `jj workspace root [OPTIONS]`

###### Options:

- `--name <NAME>` — Name of the workspace (defaults to current)

## `jj workspace update-stale`

Update a workspace that has become stale

See the stale working copy documentation for more information.

Usage: `jj workspace update-stale`

This document was generated automatically by `clap-markdown`.