Jj

Jujutsu (jj) Version Control

Agent Usage

When reading data from jj, always use --ignore-working-copy to avoid snapshotting the working copy (which is slow and unnecessary for read operations).

Non-interactive Commands (Critical)

Many jj commands spawn $EDITOR or interactive diff tools by default. These will hang indefinitely when run by agents. Always use the non-interactive alternatives:

Commands to avoid entirely (no non-interactive mode):

• jj diffedit — use jj restore or edit files directly instead
• jj config edit — use jj config set <key> <value> instead
• jj sparse edit — use jj sparse set --add <path> or --remove <path> instead
• jj resolve — edit conflict markers directly in files, or use --tool :ours / --tool :theirs

Agent-Friendly Output Formats

jj's default diff and conflict formats differ from Git's. For easier parsing, use Git-compatible formats:

Diffs: Use the --git flag for unified diff output:

jj diff --git
jj log -p --git
jj show --git

Conflicts: jj uses diff-based conflict markers by default (%%%%%%%, +++++++). For standard Git-style markers (<<<<<<<, =======, >>>>>>>), pass --config when running commands that may create conflicts:

jj --config ui.conflict-marker-style=git rebase ...
jj --config ui.conflict-marker-style=git new --insert-before ...

The conflict style is applied when conflicts are materialized to the working copy, so the config must be set before the conflict occurs.

JSON: For structured/programmatic output, use the json(self) template:

jj log --ignore-working-copy --no-graph -T 'json(self) ++ "\n"'

Outputs one JSON object per line with commit_id, change_id, description, author, etc. Works with jj log, jj show, and other commands that support -T.

Common Commands

Topics

In-depth guides on jj concepts and syntax.

• Bookmarks
• Config
• Filesets
• Glossary
• Revsets
• Templates
• Tutorial

Command Reference

Documentation generated from jj manpages. For details on any command, read the corresponding reference file.

Bisect

• jj-bisect-run

Bookmark

• 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

Config

• jj-config-edit
• jj-config-get
• jj-config-list
• jj-config-path
• jj-config-set
• jj-config-unset

File

• jj-file-annotate
• jj-file-chmod
• jj-file-list
• jj-file-search
• jj-file-show
• jj-file-track
• jj-file-untrack

General

• jj
• jj-abandon
• jj-absorb
• jj-bisect
• jj-bookmark
• jj-commit
• jj-config
• jj-describe
• jj-diff
• jj-diffedit
• jj-duplicate
• jj-edit
• jj-evolog
• jj-file
• jj-fix
• jj-gerrit
• jj-git
• jj-help
• jj-interdiff
• jj-log
• jj-metaedit
• jj-new
• jj-next
• jj-operation
• jj-parallelize
• jj-prev
• jj-rebase
• jj-redo
• jj-resolve
• jj-restore
• jj-revert
• jj-root
• jj-show
• jj-sign
• jj-sparse
• jj-split
• jj-squash
• jj-status
• jj-tag
• jj-undo
• jj-unsign
• jj-util
• jj-version
• jj-workspace

Gerrit

• jj-gerrit-upload

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

Operation

• jj-operation-abandon
• jj-operation-diff
• jj-operation-log
• jj-operation-restore
• jj-operation-revert
• jj-operation-show

Simplify

• jj-simplify-parents

Sparse

• jj-sparse-edit
• jj-sparse-list
• jj-sparse-reset
• jj-sparse-set

Tag

• jj-tag-delete
• jj-tag-list
• jj-tag-set

Util

• jj-util-completion
• jj-util-config-schema
• jj-util-exec
• jj-util-gc
• jj-util-install-man-pages
• jj-util-markdown-help

Workspace

• jj-workspace-add
• jj-workspace-forget
• jj-workspace-list
• jj-workspace-rename
• jj-workspace-root
• jj-workspace-update-stale

--- Generated from jj manpages (jj 0.37.0)

License

The content in the references/ directory is derived from the jj (Jujutsu) project and is licensed under the Apache License 2.0.

Bookmarks

Introduction

Bookmarks are named pointers to revisions (just like branches are in Git). You can move them without affecting the target revision's identity. Bookmarks automatically move when revisions are rewritten (e.g. by jj rebase). You can pass a bookmark's name to commands that want a revision as argument. For example, jj new main will create a new revision on top of the main bookmark. Use jj bookmark list to list bookmarks and jj bookmark <subcommand> to create, move, or delete bookmarks. There is currently no concept of an active/current/checked-out bookmark.

Mapping to Git branches

Jujutsu maps its bookmarks to Git branches when interacting with Git repos. For example, jj git push --bookmark foo will push the state of the foo bookmark to the foo branch on the Git remote. Similarly, if you create a bar branch in the backing Git repo, then a subsequent jj git import will create a bar bookmark (reminder: that import happens automatically in [colocated workspaces][colocated-workspaces]).

Remotes and tracked bookmarks

Jujutsu records the last seen position of a bookmark on each remote (just like Git's remote-tracking branches). This record is updated on every jj git fetch and jj git push of the bookmark. You can refer to the remembered remote bookmark positions with <bookmark name>@<remote name>, such as jj new main@origin. jj does not provide a way to manually edit these recorded positions.

A remote bookmark can be associated with a local bookmark of the same name. This is called a tracked remote bookmark (which maps to a Git remote branch when using the Git backend). When you pull a tracked bookmark from a remote, any changes compared to the current record of the remote's state will be propagated to the corresponding local bookmark, which will be created if it doesn't exist already.

!!! note "Details: how fetch pulls bookmarks"

Let's say you run jj git fetch --remote origin and, during the fetch, jj determines that the remote's main bookmark has been moved so that its target is now ahead of the local record in main@origin.

jj will then update main@origin to the new target. If main@origin is tracked, jj will also apply the change to the local bookmark main. If the local target has also been moved compared to main@origin (probably because you ran jj bookmark set main), then the two updates will be merged. If one is ahead of the other, then that target will become the new target. Otherwise, the local bookmark will become conflicted (see the "Conflicts" section below for details).

Most commands don't show the tracked remote bookmark if it has the same target as the local bookmark. The local bookmark (without @<remote name>) is considered the bookmark's desired target. Consequently, if you want to update a bookmark on a remote, you first update the bookmark locally and then push the update to the remote. If a local bookmark also exists on some remote but points to a different target there, jj log will show the bookmark name with an asterisk suffix (e.g. main*). That is meant to remind you that you may want to push the bookmark to some remote.

If you want to know the internals of bookmark tracking, consult the [Design Doc][design].

Terminology summary

• A remote bookmark is a bookmark ref on the remote. jj can find out its

actual state only when it's actively communicating with the remote. However, jj does store the last-seen position of the remote bookmark; this is the commit jj show <bookmark name>@<remote name> would show. This notion is completely analogous to Git's "remote-tracking branches".

• A tracked (remote) bookmark is defined above. You can make a remote bookmark

tracked with the `jj bookmark track` command, for example.

• A tracking (local) bookmark is the local bookmark that jj tries to keep

in sync with the tracked remote bookmark. For example, after jj bookmark track mybookmark --remote=origin, there will be a local bookmark mybookmark that's tracking the remote mybookmark@origin bookmark. A local bookmark can track a bookmark of the same name on 0 or more remotes.

The notion of tracked bookmarks serves a similar function to the Git notion of an "upstream branch". Unlike Git, a single local bookmark can be tracking remote bookmarks on multiple remotes, and the names of the local and remote bookmarks must match.

Manually tracking a bookmark

To track a bookmark permanently use jj bookmark track <bookmark name> --remote=<remote name>. It will now be imported as a local bookmark until you untrack it or it is deleted on the remote.

Example:

$ # List all available bookmarks, as we want our colleague's bookmark.
$ jj bookmark list --all
$ # Find the bookmark.
$ # [...]
$ # Actually track the bookmark.
$ jj bookmark track <bookmark name> --remote=<remote name> # Example: jj bookmark track my-feature --remote=origin
$ # From this point on, <bookmark name> will be imported when fetching from <remote name>.
$ jj git fetch --remote <remote name>
$ # A local bookmark <bookmark name> should have been created or updated while fetching.
$ jj new <bookmark name> # Do some local testing, etc.

Untracking a bookmark

To stop following a remote bookmark, you can jj bookmark untrack it. After that, subsequent fetches of that remote will no longer move the local bookmark to match the position of the remote bookmark.

Example:

$ # List all local and remote bookmarks.
$ jj bookmark list --all
$ # Find the bookmark we no longer want to track.
$ # [...]
# # Actually untrack it.
$ jj bookmark untrack <bookmark name> --remote=<remote name> # Example: jj bookmark untrack stuff --remote=origin
$ # From this point on, this remote bookmark won't be imported anymore.
$ # The local bookmark (e.g. stuff) is unaffected. It may or may not still
$ # be tracking bookmarks on other remotes (e.g. stuff@upstream).

Listing tracked bookmarks

To list tracked bookmarks, you can jj bookmark list --tracked or jj bookmark list -t. This command omits local Git-tracking bookmarks by default.

You can see if a specific bookmark is tracked with jj bookmark list --tracked <bookmark name>.

Automatic tracking of bookmarks & auto-track-bookmarks option

There are two situations where jj tracks bookmarks automatically. jj git clone automatically sets up the default remote bookmark (e.g. main@origin) as tracked. When you push a local bookmark, the newly created bookmark on the remote is marked as tracked.

By default, every other remote bookmark is marked as "not tracked" when it's fetched. If desired, you need to manually jj bookmark track them. This works well for repositories where multiple people work on a large number of bookmarks.

The default can be changed by setting the config remotes.<name>.auto-track-bookmarks = "*". Then, jj git fetch tracks every newly fetched bookmark with a local bookmark. Branches that already existed before the jj git fetch are not affected. This is similar to Mercurial, which fetches all its bookmarks (equivalent to Git's branches) by default. Similarly, all newly created local bookmarks will be marked as "tracked", preparing them to be pushed with the next jj git push command. See "Automatic tracking of bookmarks" for details.

Bookmark updates

Currently Jujutsu automatically updates local bookmarks when these conditions are met:

• When a commit has been rewritten (e.g, when you rebase) bookmarks and the

working-copy will move along with it.

• When a commit has been abandoned, all associated bookmarks will be deleted.

You could describe the updates as following along the change-id of the current bookmark commit, even if it isn't entirely accurate.

Pushing bookmarks: Safety checks

Before jj git push actually moves, creates, or deletes a remote bookmark, it makes several safety checks.

1. jj will contact the remote and check that the actual state of the remote bookmark matches jj's record of its last known position. If there is a conflict, jj will refuse to push the bookmark. In this case, you need to run jj git fetch --remote <remote name> and resolve the resulting bookmark conflict. Then, you can try jj git push again.

If you are familiar with Git, this makes jj git push similar to git push --force-with-lease.

There are a few cases where jj git push will succeed even though the remote bookmark is in an unexpected location. These are the cases where jj git fetch would not create a bookmark conflict and would not move the local bookmark, e.g. if the unexpected location is identical to the local position of the bookmark.

2. The local bookmark must not be conflicted. If it is, you would need to use jj bookmark move, for example, to resolve the conflict.

This makes jj git push safe even if jj git fetch is performed on a timer in the background (this situation is a known issue[^known-issue] with some forms of git push --force-with-lease). If the bookmark moves on a remote in a problematic way, jj git fetch will create a conflict. This should ensure that the user becomes aware of the conflict before they can jj git push and override the bookmark on the remote.

3. If the remote bookmark already exists on the remote, it must be tracked.

[^known-issue]: See "A general note on safety" in <https://git-scm.com/docs/git-push#Documentation/git-push.txt---no-force-with-lease>

Conflicts

Bookmarks can end up in a conflicted state. When that happens, jj status will include information about the conflicted bookmarks (and instructions for how to mitigate it). jj bookmark list will have details. jj log will show the bookmark name with a double question mark suffix (e.g. main??) on each of the conflicted bookmark's potential target revisions. Using the bookmark name to look up a revision will resolve to all potential targets. That means that jj new main will error out, complaining that the revset resolved to multiple revisions.

Both local bookmarks (e.g. main) and the remote bookmark (e.g. main@origin) can have conflicts. Both can end up in that state if concurrent operations were run in the repo. The local bookmark more typically becomes conflicted because it was updated both locally and on a remote.

To resolve a conflicted state in a local bookmark (e.g. main), you can move the bookmark to the desired target with jj bookmark move. You may want to first either merge the conflicted targets with jj new (e.g. jj new main), or you may want to rebase one side on top of the other with jj rebase.

To resolve a conflicted state in a remote bookmark (e.g. main@origin), simply pull from the remote (e.g. jj git fetch). The conflict resolution will also propagate to the local bookmark (which was presumably also conflicted).

Ease of use

The use of bookmarks is frequent in some workflows, for example, when interacting with Git repositories containing branches. To this end, one-letter shortcuts have been implemented, both for the jj bookmark command itself through an alias (as jj b), and for its subcommands. For example, jj bookmark create BOOKMARK-NAME -r@ can be abbreviated as jj b c BOOKMARK-NAME -r@.

[colocated-workspaces]: git-compatibility.md#colocated-jujutsugit-repos [design]: design/tracking-branches.md

Filesets

Jujutsu supports a functional language for selecting a set of files. Expressions in this language are called "filesets" (the idea comes from Mercurial). The language consists of file patterns, operators, and functions.

Quoting file names

Many jj commands accept fileset expressions as positional arguments. File names passed to these commands [must be quoted][string-literals] if they contain whitespace or meta characters. However, as a special case, quotes can be omitted if the expression has no operators nor function calls. For example:

• jj diff 'Foo Bar' (shell quotes are required, but inner quotes are optional)
• jj diff '~"Foo Bar"' (both shell and inner quotes are required)
• jj diff '"Foo(1)"' (both shell and inner quotes are required)

Glob characters aren't considered meta characters, but shell quotes are still required:

• jj diff '~glob:**/*.rs'

[string-literals]: templates.md#stringliteral-type

File patterns

The following patterns are supported. In all cases, we do not mention any shell quoting that might be necessary, and the quotes around "path" are optional if the path has no special characters.

By default, "path" is parsed as a prefix-glob: pattern, which matches cwd-relative path prefix.

• cwd:"path": Matches cwd-relative path prefix (file or files under directory

recursively.)

• file:"path" or cwd-file:"path": Matches cwd-relative file (or exact) path.
• glob:"pattern" or cwd-glob:"pattern": Matches file paths with cwd-relative

Unix-style shell [wildcard pattern][glob]. For example, glob:"*.c" will match all .c files in the current working directory non-recursively.

• prefix-glob:"pattern" or cwd-prefix-glob:"pattern": Like glob:, but also

matches path prefix (file or files under directory recursively.) For example, prefix-glob:"*.d" is equivalent to glob:"*.d" | glob:"*.d/**".

• root:"path": Matches workspace-relative path prefix (file or files under

directory recursively.)

• root-file:"path": Matches workspace-relative file (or exact) path.
• root-glob:"pattern": Matches file paths with workspace-relative Unix-style

shell [wildcard pattern][glob].

• root-prefix-glob:"pattern": Like root-glob:, but also matches path prefix

(file or files under directory recursively.)

Glob patterns support case-insensitive matching by appending -i to the pattern name. For example, glob-i:"*.TXT" will match both file.txt and FILE.TXT.

[glob]: https://docs.rs/globset/latest/globset/#syntax

Operators

The following operators are supported. x and y below can be any fileset expressions.

• ~x: Matches everything but x.
• x & y: Matches both x and y.
• x ~ y: Matches x but not y.
• x | y: Matches either x or y (or both).

(listed in order of binding strengths)

You can use parentheses to control evaluation order, such as (x & y) | z or x & (y | z).

Functions

You can also specify patterns by using functions.

• all(): Matches everything.
• none(): Matches nothing.

Examples

Show diff excluding Cargo.lock.

jj diff '~Cargo.lock'

List files in src excluding Rust sources.

jj file list 'src ~ glob:"**/*.rs"'

Split a revision in two, putting foo into the second commit.

jj split '~foo'

Glossary

Anonymous branch

An anonymous branch is a chain of commits that doesn't necessarily have any bookmarks pointing to it or to any of its descendants. Unlike Git, Jujutsu keeps commits on anonymous branches around until they are explicitly abandoned. Visible anonymous branches are tracked by the view, which stores a list of heads of such branches.

Backend

A backend is an implementation of the storage layer. There is currently only one production-ready builtin commit backend: the Git backend. The Git backend stores commits in a Git repository. There are several backends used for testing. Google also has its own cloud-based backend.

There are also pluggable backends for storing other information than commits, such as the "operation store backend" for storing the operation log.

Bookmark

A bookmark is a named pointer to a commit. They are similar to Git's branches and even more similar to Mercurial's bookmarks. See here for details.

Unlike in Git, there is no concept of a "current bookmark"; bookmarks do not move when you create a new commit. Bookmarks do automatically follow the commit if it gets rewritten.

Branch

In the context of jj, the word "branch" usually refers to an anonymous branch or, less formally, a branch of the commit "tree" (which is itself an informal way to refer to the commit graph, parts of which might resemble a tree even when it's not mathematically a tree).

We also sometimes discuss Git's branches and branches on Git remotes. Locally, these correspond to bookmarks. In a colocated workspace, each local Git branch corresponds to a jj bookmark.

Change

A change is a commit as it evolves over time. Changes themselves don't exist as an object in the data model; only the change ID does. The change ID is a property of a commit.

Change ID

A change ID is a unique identifier for a change. They are typically 16 bytes long and are often randomly generated. By default, jj log presents them as a sequence of 12 letters in the k-z range, at the beginning of a line. These are actually hexadecimal numbers that use "digits" z-k instead of 0-9a-f.

Change offset

Sometimes a change ID might not unambiguously identify a commit, such as if the commit is hidden or if the change ID is divergent. In these cases, you can add an offset after the change ID to make it clear which commit you are referring to, with the most recent commit having an offset of 0. For instance, the most recent commit with change ID xyz could be referred to as xyz/0, while the one before it would be xyz/1, and so on.

Commit

A snapshot of the files in the repository at a given point in time (technically a tree object), together with some metadata. The metadata includes the author, the date, and pointers to the commit's parents. Through the pointers to the parents, the commits form a Directed Acyclic Graph (DAG) .

Note that even though commits are stored as snapshots, they are often treated as differences between snapshots, namely compared to their parent's snapshot. If they have more than one parent, then the difference is computed against the result of merging the parents. For example, jj diff will show the differences introduced by a commit compared to its parent(s), and jj rebase will apply those changes onto another base commit.

The word "revision" is used as a synonym for "commit".

Commit ID

A commit ID is a unique identifier for a commit. They are 20 bytes long when using the Git backend. They are presented in regular hexadecimal format at the end of the line in jj log, using 12 hexadecimal digits by default. When using the Git backend, the commit ID is the Git commit ID.

<a name="colocated-repos"></a>Colocated workspaces

When using the Git backend and the backing Git repository's .git/ directory is a sibling of .jj/, we call the workspace colocated. Most tools designed for Git can be easily used on such workspace. jj and git commands can be used interchangeably.

See here for details.

Conflict

Conflicts can occur in many places. The most common type is conflicts in files. Those are the conflicts that users coming from other VCSs are usually familiar with. You can see them in jj status and in jj log (the red "conflict" label at the end of the line). See here for details.

Conflicts can also occur in bookmarks. For example, if you moved a bookmark locally, and it was also moved on the remote, then the bookmark will be in a conflicted state after you pull from the remote. See here for details.

Similar to a bookmark conflict, when a change is rewritten locally and remotely, for example, then the change will be in a conflicted state. We call that a divergent change.

Divergent change

A divergent change is a change that has more than one visible commit. These changes are displayed with a label of "divergent" in the log.

Head

A head is a commit with no descendants. The context in which it has no descendants varies. For example, the heads(X) revset function returns commits that have no descendants within the set X itself. The view records which anonymous heads (heads without a bookmark pointing to them) are visible at a given operation. Note that this is quite different from Git's HEAD.

Hidden commits, abandoned commits

See visible commits.

Operation

A snapshot of the visible commits and bookmarks at a given point in time (technically a view object), together with some metadata. The metadata includes the username, hostname, timestamps, and pointers to the operation's parents.

Operation log

The operation log is the DAG formed by operation objects, much in the same way that commits form a DAG, which is sometimes called the "commit history". When operations happen in sequence, they form a single line in the graph. Operations that happen concurrently from jj's perspective result in forks and merges in the DAG.

Repository

Basically everything under .jj/, i.e. the full set of operations and commits.

Remote

A remote is a reference to a copy of your repository. The most common case is that the remote is hosted on the internet or another network, but local remotes are also possible. Remotes are useful when working on a project with multiple collaborators. As Jujutsu is compatible with Git you can use all popular providers that are also available for Git. For example GitHub, GitLab or Codeberg.

Revision

A synonym for Commit.

Revset

Jujutsu supports a functional language for selecting a set of revisions. Expressions in this language are called "revsets". See here for details. We also often use the term "revset" for the set of revisions selected by a revset.

Rewrite

To "rewrite" a commit means to create a new version of that commit with different contents, metadata (including parent pointers), or both. Rewriting a commit results in a new commit, and thus a new commit ID, but the change ID generally remains the same. Some examples of rewriting a commit would be changing its description or rebasing it. Modifying the working copy rewrites the working copy commit.

Root commit

The root commit is a virtual commit at the root of every repository. It has a commit ID consisting of all '0's (00000000...) and a change ID consisting of all 'z's (zzzzzzzz...). It can be referred to in revsets by the function root(). Note that our definition of "root commit" is different from Git's; Git's "root commits" are the first commit(s) in the repository, i.e. the commits jj log -r 'root()+' will show.

Tree

A tree object represents a snapshot of a directory in the repository. Tree objects are defined recursively; each tree object only has the files and directories contained directly in the directory it represents.

Tracked bookmarks and tracking bookmarks

A remote bookmark can be made "tracked" with the jj bookmark track command. This results in a "tracking" local bookmark that tracks the remote bookmark.

See the bookmarks documentation for a more detailed definition of these terms.

Visible commits

Visible commits are the commits you see in jj log -r 'all()'. They are the commits that are reachable from an anonymous head in the view. Ancestors of a visible commit are implicitly visible.

Intuitively, visible commits are the "latest versions" of a given change. A commit that's abandoned or rewritten stops being visible and is labeled as "hidden". Such commits are no longer accessible using a change id, but they are still accessible by their commit id.

View

A view is a snapshot of bookmarks and their targets, anonymous heads, and working-copy commits. The anonymous heads define which commits are visible.

A view object is similar to a tree object in that it represents a snapshot without history, and an operation object is similar to a commit object in that it adds metadata and history.

Workspace

A workspace is a working copy and an associated repository. There can be multiple workspaces for a single repository. Each workspace has a .jj/ directory, but the commits and operations will be stored in the initial workspace; the other workspaces will have pointers to the initial workspace. See here for details.

This is what Git calls a "worktree".

Working copy

The working copy contains the files you're currently working on. It is automatically snapshot at the beginning of almost every jj command, thus creating a new working-copy commit if any changes had been made in the working copy. Conversely, the working copy is automatically updated to the state of the working-copy commit at the end of almost every jj command. See here for details.

This is what Git calls a "working tree".

Working-copy commit

A commit that corresponds to the current state of the working copy. There is one working-copy commit per workspace. The current working-copy commits are tracked in the operation log.

NAME

jj-abandon - Abandon a revision

SYNOPSIS

jj abandon \[\--retain-bookmarks\] \[\--restore-descendants\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[REVSETS\]

DESCRIPTION

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.

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

-h, \--help

: Print help (see a summary with -h)

\[REVSETS\]

: The revision(s) to abandon (default: @) \[aliases: -r\]

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-absorb - Move changes from a revision into the stack of mutable revisions

SYNOPSIS

jj absorb \[-f\|\--from\] \[-t\|\--into\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[FILESETS\]

DESCRIPTION

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

OPTIONS

-f, \--from \<REVSET\> \[default: @\]

: Source revision to absorb from

-t, \--into \<REVSETS\> \[default: mutable()\]

: Destination revisions to absorb into

Only ancestors of the source revision will be considered.

-h, \--help

: Print help (see a summary with -h)

\[FILESETS\]

: Move only changes to these paths (instead of all paths)

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bisect-run - Run a given command to find the first bad revision

SYNOPSIS

jj bisect run \<-r\|\--range\> \[\--find-good\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[COMMAND\] \[ARGS\]

DESCRIPTION

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\"\

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

-h, \--help

: Print help (see a summary with -h)

\[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 targets 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\.

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bisect - Find a bad revision by bisection

SYNOPSIS

jj bisect \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<subcommands\>

DESCRIPTION

Find a bad revision by bisection

OPTIONS

-h, \--help

: Print help (see a summary with -h)

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

SUBCOMMANDS

jj-bisect-run(1)

: Run a given command to find the first bad revision

NAME

jj-bookmark-create - Create a new bookmark

SYNOPSIS

jj bookmark create \[-r\|\--revision\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAMES\>

DESCRIPTION

Create a new bookmark

OPTIONS

-r, \--revision \<REVSET\> \[default: @\]

: The bookmarks target revision

-h, \--help

: Print help (see a summary with -h)

\<NAMES\>

: The bookmarks to create

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

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

SYNOPSIS

jj bookmark delete \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAMES\>

DESCRIPTION

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 dont want the deletion of the local bookmark to propagate to any tracked remote bookmarks, use \jj bookmark forget\ instead.

OPTIONS

-h, \--help

: Print help (see a summary with -h)

\<NAMES\>

: The bookmarks to delete

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

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-forget - Forget a bookmark without marking it as a deletion to be pushed

SYNOPSIS

jj bookmark forget \[\--include-remotes\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAMES\>

DESCRIPTION

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.

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.

-h, \--help

: Print help (see a summary with -h)

\<NAMES\>

: The bookmarks to forget

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

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-list - List bookmarks and their targets

SYNOPSIS

jj bookmark list \[-a\|\--all-remotes\] \[\--remote\] \[-t\|\--tracked\] \[-c\|\--conflicted\] \[-r\|\--revisions\] \[-T\|\--template\] \[\--sort\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[NAMES\]

DESCRIPTION

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

\[\jj help -k bookmarks\\]: https://docs.jj-vcs.dev/latest/bookmarks

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\].

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

-t, \--tracked

: Show tracked remote bookmarks only

This omits local Git-tracking bookmarks by default.

-c, \--conflicted

: Show conflicted bookmarks only

-r, \--revisions \<REVSETS\>

: Show bookmarks whose local targets are in the given revisions

Note that \-r deleted_bookmark\ will not work since \deleted_bookmark\ wouldnt 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.

\[\CommitRef\ type\]: https://docs.jj-vcs.dev/latest/templates/#commitref-type

\[\jj help -k templates\\]: https://docs.jj-vcs.dev/latest/templates/

\--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-\]

-h, \--help

: Print help (see a summary with -h)

\[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\].

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-move - Move existing bookmarks to target revision

SYNOPSIS

jj bookmark move \[-f\|\--from\] \[-t\|\--to\] \[-B\|\--allow-backwards\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[NAMES\]

DESCRIPTION

Move existing bookmarks to target revision

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.

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

\$ jj bookmark move \--from heads(::@- & bookmarks()) \--to @-

OPTIONS

-f, \--from \<REVSETS\>

: Move bookmarks from the given revisions

-t, \--to \<REVSET\> \[default: @\]

: Move bookmarks to this revision

-B, \--allow-backwards

: Allow moving bookmarks backwards or sideways

-h, \--help

: Print help (see a summary with -h)

\[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\].

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-rename - Rename \old\ bookmark name to \new\ bookmark name

SYNOPSIS

jj bookmark rename \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<OLD\> \<NEW\>

DESCRIPTION

Rename \old\ bookmark name to \new\ bookmark name

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

OPTIONS

-h, \--help

: Print help (see a summary with -h)

\<OLD\>

: The old name of the bookmark

\<NEW\>

: The new name of the bookmark

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-set - Create or update a bookmark to point to a certain commit

SYNOPSIS

jj bookmark set \[-r\|\--revision\] \[-B\|\--allow-backwards\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAMES\>

DESCRIPTION

Create or update a bookmark to point to a certain commit

OPTIONS

-r, \--revision \<REVSET\> \[default: @\]

: The bookmarks target revision

-B, \--allow-backwards

: Allow moving the bookmark backwards or sideways

-h, \--help

: Print help (see a summary with -h)

\<NAMES\>

: The bookmarks to update

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-track - Start tracking given remote bookmarks

SYNOPSIS

jj bookmark track \[\--remote\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<BOOKMARK\>

DESCRIPTION

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.

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.

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

-h, \--help

: Print help (see a summary with -h)

\<BOOKMARK\>

: Bookmark names to track

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

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark-untrack - Stop tracking given remote bookmarks

SYNOPSIS

jj bookmark untrack \[\--remote\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<BOOKMARK\>

DESCRIPTION

Stop tracking given remote bookmarks

An untracked remote bookmark is just a pointer to the last-fetched remote bookmark. It wont 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.

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.

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

-h, \--help

: Print help (see a summary with -h)

\<BOOKMARK\>

: Bookmark names to untrack

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

\[string pattern syntax\]: https://docs.jj-vcs.dev/latest/revsets/#string-patterns

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-bookmark - Manage bookmarks \[default alias: b\]

SYNOPSIS

jj bookmark \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<subcommands\>

DESCRIPTION

Manage bookmarks \[default alias: b\]

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

\[\jj help -k bookmarks\\]: https://docs.jj-vcs.dev/latest/bookmarks

OPTIONS

-h, \--help

: Print help (see a summary with -h)

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

SUBCOMMANDS

jj-bookmark-create(1)

: Create a new bookmark

jj-bookmark-delete(1)

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

jj-bookmark-forget(1)

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

jj-bookmark-list(1)

: List bookmarks and their targets

jj-bookmark-move(1)

: Move existing bookmarks to target revision

jj-bookmark-rename(1)

: Rename \old\ bookmark name to \new\ bookmark name

jj-bookmark-set(1)

: Create or update a bookmark to point to a certain commit

jj-bookmark-track(1)

: Start tracking given remote bookmarks

jj-bookmark-untrack(1)

: Stop tracking given remote bookmarks

NAME

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

SYNOPSIS

jj commit \[-i\|\--interactive\] \[\--tool\] \[-m\|\--message\] \[\--editor\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[FILESETS\]

DESCRIPTION

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\ doesnt 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\ doesnt move bookmarks forward.

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

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 (dont 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.

-h, \--help

: Print help (see a summary with -h)

\[FILESETS\]

: Put these paths in the current commit

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-config-edit - Start an editor on a jj config file

SYNOPSIS

jj config edit \[\--user\] \[\--repo\] \[\--workspace\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\]

DESCRIPTION

Start an editor on a jj config file.

Creates the file if it doesnt already exist regardless of what the editor does.

OPTIONS

\--user

: Target the user-level config

\--repo

: Target the repo-level config

\--workspace

: Target the workspace-level config

-h, \--help

: Print help (see a summary with -h)

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-config-get - Get the value of a given config option.

SYNOPSIS

jj config get \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAME\>

DESCRIPTION

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

OPTIONS

-h, \--help

: Print help (see a summary with -h)

\<NAME\>

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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-config-list - List variables set in config files, along with their values

SYNOPSIS

jj config list \[\--include-defaults\] \[\--include-overridden\] \[\--user\] \[\--repo\] \[\--workspace\] \[-T\|\--template\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \[NAME\]

DESCRIPTION

List variables set in config files, along with their values

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 \[TOMLs \"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.

\[TOMLs \"dotted key\" format\]: https://toml.io/en/v1.0.0#keys

\[\jj help -k templates\\]: https://docs.jj-vcs.dev/latest/templates/

-h, \--help

: Print help (see a summary with -h)

\[NAME\]

: An optional name of a specific config option to look up

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-config-path - Print the paths to the config files

SYNOPSIS

jj config path \[\--user\] \[\--repo\] \[\--workspace\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\]

DESCRIPTION

Print the paths to the config files

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

See \jj config edit\ if youd like to immediately edit a file.

OPTIONS

\--user

: Target the user-level config

\--repo

: Target the repo-level config

\--workspace

: Target the workspace-level config

-h, \--help

: Print help (see a summary with -h)

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

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

SYNOPSIS

jj config set \[\--user\] \[\--repo\] \[\--workspace\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAME\> \<VALUE\>

DESCRIPTION

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

OPTIONS

\--user

: Target the user-level config

\--repo

: Target the repo-level config

\--workspace

: Target the workspace-level config

-h, \--help

: Print help (see a summary with -h)

\<NAME\>

:

\<VALUE\>

: New value to set

The value should be specified as a TOML expression. If string value isnt 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 \"{dont}\" use \jj config set \--user foo.bar \"{dont}\"\. 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.

GLOBAL 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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)

NAME

jj-config-unset - Update a config file to unset the given option

SYNOPSIS

jj config unset \[\--user\] \[\--repo\] \[\--workspace\] \[-R\|\--repository\] \[\--ignore-working-copy\] \[\--ignore-immutable\] \[\--at-operation\] \[\--debug\] \[\--color\] \[\--quiet\] \[\--no-pager\] \[\--config\] \[\--config-file\] \[-h\|\--help\] \<NAME\>

DESCRIPTION

Update a config file to unset the given option

OPTIONS

\--user

: Target the user-level config

\--repo

: Target the repo-level config

\--workspace

: Target the workspace-level config

-h, \--help

: Print help (see a summary with -h)

\<NAME\>

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

: Dont snapshot the working copy, and dont update it

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

Loading the repository at a specific operation with \\--at-operation\ implies \\--ignore-working-copy\.

\--ignore-immutable

: Allow rewriting immutable commits

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

This option only affects the check. It does not affect the \immutable_heads()\ revset or the \immutable\ template keyword.

\--at-operation \<AT_OPERATION\>

: Operation to load the repo at

Operation to load the repo at. By default, Jujutsu loads the repo at the most recent operation, 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. Theres 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 wont 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 isnt enclosed by any TOML constructs (such as array notation), quotes can be omitted.

\--config-file \<PATH\>

: Additional configuration files (can be repeated)