jj Workspace

4 months ago 23

Warning

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

Run jj help <COMMAND> for more authoritative documentation.

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

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

Command Overview:

jj

Jujutsu (An experimental VCS)

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

Usage: jj [OPTIONS] [COMMAND]

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

Subcommands:
  • abandon — Abandon a revision
  • absorb — Move changes from a revision into the stack of mutable revisions
  • bookmark — Manage bookmarks [default alias: b]
  • commit — Update the description and create a new change on top
  • config — Manage config options
  • describe — Update the change description or other metadata
  • diff — Compare file contents between two revisions
  • diffedit — Touch up the content changes in a revision with a diff editor
  • duplicate — Create new changes with the same content as existing ones
  • edit — Sets the specified revision as the working-copy revision
  • evolog — Show how a change has evolved over time
  • file — File operations
  • fix — Update files with formatting fixes or other changes
  • git — Commands for working with Git remotes and the underlying Git repo
  • help — Print this message or the help of the given subcommand(s)
  • interdiff — Compare the changes of two commits
  • log — Show revision history
  • new — Create a new, empty change and (by default) edit it in the working copy
  • next — Move the working-copy commit to the child revision
  • operation — Commands for working with the operation log
  • parallelize — Parallelize revisions by making them siblings
  • prev — Change the working copy revision relative to the parent revision
  • rebase — Move revisions to different parent(s)
  • resolve — Resolve conflicted files with an external merge tool
  • restore — Restore paths from another revision
  • revert — Apply the reverse of the given revision(s)
  • root — Show the current workspace root directory (shortcut for jj workspace root)
  • show — Show commit description and changes in a revision
  • sign — Cryptographically sign a revision
  • simplify-parents — Simplify parent edges for the specified revision(s)
  • sparse — Manage which paths from the working-copy commit are present in the working copy
  • split — Split a revision in two
  • squash — Move changes from a revision into another revision
  • status — Show high-level repo status
  • tag — Manage tags
  • util — Infrequently used commands such as for generating shell completions
  • undo — Undo an operation (shortcut for jj op undo)
  • unsign — Drop a cryptographic signature
  • version — Display version information
  • workspace — Commands for working with workspaces
Options:

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

    By default, Jujutsu searches for the closest .jj/ directory in an ancestor of the current working directory.

  • --ignore-working-copy — Don't snapshot the working copy, and don't update it

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

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

  • --ignore-immutable — Allow rewriting immutable commits

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

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

  • --at-operation <AT_OPERATION> [alias: at-op] — Operation to load the repo at

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

    You can use --at-op=<operation ID> to see what the repo looked like at an earlier operation. For example jj --at-op=<operation ID> st will show you what jj st would have shown you when the given operation had just finished. --at-op=@ is pretty much the same as the default except that divergent operations will never be merged.

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

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

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

  • --debug — Enable debug logging

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

    Possible values: always, never, debug, auto

  • --quiet — Silence non-primary command output

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

    Warnings and errors will still be printed.

  • --no-pager — Disable the pager

  • --config <NAME=VALUE> — Additional configuration options (can be repeated)

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

  • --config-file <PATH> — Additional configuration files (can be repeated)

jj abandon

Abandon a revision

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

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

Usage: jj abandon [OPTIONS] [REVSETS]...

Arguments:
  • <REVSETS> — The revision(s) to abandon (default: @)
Options:

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

    Bookmarks will be moved to the parent revisions instead.

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

jj absorb

Move changes from a revision into the stack of mutable revisions

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

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

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

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

Arguments:
  • <FILESETS> — Move only changes to these paths (instead of all paths)
Options:

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

    Default value: @

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

    Only ancestors of the source revision will be considered.

    Default value: mutable()

jj bookmark

Manage bookmarks [default alias: b]

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

Usage: jj bookmark <COMMAND>

Subcommands:
  • create — Create a new bookmark
  • delete — Delete an existing bookmark and propagate the deletion to remotes on the next push
  • forget — Forget a bookmark without marking it as a deletion to be pushed
  • list — List bookmarks and their targets
  • move — Move existing bookmarks to target revision
  • rename — Rename old bookmark name to new bookmark name
  • set — Create or update a bookmark to point to a certain commit
  • track — Start tracking given remote bookmarks
  • untrack — Stop tracking given remote bookmarks

jj bookmark create

Create a new bookmark

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

Command Alias: c

Arguments:
  • <NAMES> — The bookmarks to create
Options:
  • -r, --revision <REVSET> [alias: to] — The bookmark's target revision

jj bookmark delete

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

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

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

Usage: jj bookmark delete <NAMES>...

Command Alias: d

Arguments:

  • <NAMES> — The bookmarks to delete

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

jj bookmark forget

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

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

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

Command Alias: f

Arguments:

  • <NAMES> — The bookmarks to forget

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

Options:

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

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

jj bookmark list

List bookmarks and their targets

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

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

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

Command Alias: l

Arguments:

  • <NAMES> — Show bookmarks whose local name matches

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

Options:
  • -a, --all-remotes — Show all tracking and non-tracking remote bookmarks including the ones whose targets are synchronized with the local bookmarks

  • --remote <REMOTE> — Show all tracking and non-tracking 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 remote name matches exactly. Use glob: prefix to select remotes by wildcard pattern.

  • -t, --tracked — Show remote tracked bookmarks only. 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 wouldn't have a local target.

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

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

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

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

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

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

jj bookmark move

Move existing bookmarks to target revision

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

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

Command Alias: m

Arguments:

  • <NAMES> — Move bookmarks matching the given name patterns

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

Options:
  • -f, --from <REVSETS> — Move bookmarks from the given revisions
  • -t, --to <REVSET> — Move bookmarks to this revision
  • -B, --allow-backwards — Allow moving bookmarks backwards or sideways

jj bookmark rename

Rename old bookmark name to new bookmark name

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

Usage: jj bookmark rename <OLD> <NEW>

Command Alias: r

Arguments:
  • <OLD> — The old name of the bookmark
  • <NEW> — The new name of the bookmark

jj bookmark set

Create or update a bookmark to point to a certain commit

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

Command Alias: s

Arguments:
  • <NAMES> — The bookmarks to update
Options:
  • -r, --revision <REVSET> [alias: to] — The bookmark's target revision
  • -B, --allow-backwards — Allow moving the bookmark backwards or sideways

jj bookmark track

Start tracking given remote bookmarks

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

Usage: jj bookmark track <BOOKMARK@REMOTE>...

Command Alias: t

Arguments:

  • <BOOKMARK@REMOTE> — Remote bookmarks to track

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

    Examples: bookmark@remote, glob:main@, glob:jjfan-@upstream

jj bookmark untrack

Stop tracking given remote bookmarks

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

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

Usage: jj bookmark untrack <BOOKMARK@REMOTE>...

Arguments:

  • <BOOKMARK@REMOTE> — Remote bookmarks to untrack

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

    Examples: bookmark@remote, glob:main@, glob:jjfan-@upstream

jj commit

Update the description and create a new change on top

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

Arguments:
  • <FILESETS> — Put these paths in the first commit
Options:
  • -i, --interactive — Interactively choose which changes to include in the first commit
  • --tool <NAME> — Specify diff editor to be used (implies --interactive)
  • -m, --message <MESSAGE> — The change description to use (don't open editor)

  • --reset-author — Reset the author to the configured user

    This resets the author name, email, and timestamp.

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

    $ JJ_USER='Foo Bar' [email protected] jj commit --reset-author

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

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

jj config

Manage config options

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

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

Usage: jj config <COMMAND>

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

jj config edit

Start an editor on a jj config file.

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

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

Command Alias: e

Options:
  • --user — Target the user-level config
  • --repo — Target the repo-level config

jj config get

Get the value of a given config option.

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

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

Usage: jj config get <NAME>

Command Alias: g

Arguments:
  • <NAME>

jj config list

List variables set in config files, along with their values

Usage: jj config list [OPTIONS] [NAME]

Command Alias: l

Arguments:
  • <NAME> — An optional name of a specific config option to look up
Options:
  • --include-defaults — Whether to explicitly include built-in default values in the list
  • --include-overridden — Allow printing overridden values
  • --user — Target the user-level config
  • --repo — Target the repo-level config

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

    The following keywords are available in the template expression:

    • name: String: Config name.
    • value: ConfigValue: Value to be formatted in TOML syntax.
    • overridden: Boolean: True if the value is shadowed by other.
    • source: String: Source of the value.
    • path: String: Path to the config file.

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

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

jj config path

Print the paths to the config files

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

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

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

Command Alias: p

Options:
  • --user — Target the user-level config
  • --repo — Target the repo-level config

jj config set

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

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

Command Alias: s

Arguments:
  • <NAME>

  • <VALUE> — New value to set

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

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

Options:
  • --user — Target the user-level config
  • --repo — Target the repo-level config

jj config unset

Update a config file to unset the given option

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

Command Alias: u

Arguments:
  • <NAME>
Options:
  • --user — Target the user-level config
  • --repo — Target the repo-level config

jj describe

Update the change description or other metadata

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

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

Command Alias: desc

Arguments:
  • <REVSETS> — The revision(s) whose description to edit (default: @)
Options:

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

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

  • --stdin — Read the change description from stdin

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

  • --no-edit — Don't open an editor

    This is mainly useful in combination with e.g. --reset-author.

  • --edit — Open an editor

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

  • --reset-author — Reset the author to the configured user

    This resets the author name, email, and timestamp.

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

    $ JJ_USER='Foo Bar' [email protected] jj describe --reset-author

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

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

jj diff

Compare file contents between two revisions

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

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

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

Arguments:
  • <FILESETS> — Restrict the diff to these paths
Options:

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

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

    If a revision is a merge commit, this shows changes from the automatic merge of the contents of all of its parents to the contents of the revision itself.

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

  • -t, --to <REVSET> — Show changes to this revision
  • -s, --summary — For each path, show only whether it was modified, added, or deleted
  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • -w, --ignore-all-space — Ignore whitespace when comparing lines
  • -b, --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj diffedit

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

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

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

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

See jj restore if you want to move entire files from one revision to another. For moving changes between revisions, see jj squash -i.

Usage: jj diffedit [OPTIONS]

Options:

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

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

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

    Defaults to @ if --to is specified.

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

    Defaults to @ if --from is specified.

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

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

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

jj duplicate

Create new changes with the same content as existing ones

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

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

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

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

Arguments:
  • <REVSETS> — The revision(s) to duplicate (default: @)
Options:
  • -d, --destination <REVSETS> — The revision(s) to duplicate onto (can be repeated to create a merge commit)
  • -A, --insert-after <REVSETS> [alias: after] — The revision(s) to insert after (can be repeated to create a merge commit)
  • -B, --insert-before <REVSETS> [alias: before] — The revision(s) to insert before (can be repeated to create a merge commit)

jj edit

Sets the specified revision as the working-copy revision

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

Usage: jj edit <REVSET>

Arguments:
  • <REVSET> — The commit to edit

jj evolog

Show how a change has evolved over time

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

Usage: jj evolog [OPTIONS]

Command Alias: evolution-log

Options:

  • -r, --revision <REVSET>

    Default value: @

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

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

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

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

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

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

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

  • -p, --patch — Show patch compared to the previous version of this change

    If the previous version has different parents, it will be temporarily rebased to the parents of the new version, so the diff is not contaminated by unrelated changes.

  • -s, --summary — For each path, show only whether it was modified, added, or deleted

  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj file

File operations

Usage: jj file <COMMAND>

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

jj file annotate

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

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

Usage: jj file annotate [OPTIONS] <PATH>

Arguments:
  • <PATH> — the file to annotate
Options:
  • -r, --revision <REVSET> — an optional revision to start at

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

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

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

jj file chmod

Sets or removes the executable bit for paths in the repo

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

Usage: jj file chmod [OPTIONS] <MODE> <FILESETS>...

Arguments:

  • <MODE>

    Possible values:

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

  • <FILESETS> — Paths to change the executable bit for

Options:

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

    Default value: @

jj file list

List files in a revision

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

Arguments:
  • <FILESETS> — Only list files matching these prefixes (instead of all files)
Options:

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

    Default value: @

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

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

jj file show

Print contents of files in a revision

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

Usage: jj file show [OPTIONS] <FILESETS>...

Arguments:
  • <FILESETS> — Paths to print
Options:

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

    Default value: @

jj file track

Start tracking specified paths in the working copy

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

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

Usage: jj file track <FILESETS>...

Arguments:
  • <FILESETS> — Paths to track

jj file untrack

Stop tracking specified paths in the working copy

Usage: jj file untrack <FILESETS>...

Arguments:

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

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

jj fix

Update files with formatting fixes or other changes

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

The changed files in the given revisions will be updated with any fixes determined by passing their file content through any external tools the user has configured for those files. Descendants will also be updated by passing their versions of the same files through the same tools, which will ensure that the fixes are not lost. This will never result in new conflicts. Files with existing conflicts will be updated on all sides of the conflict, which can potentially increase or decrease the number of conflict markers.

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

Tools are defined in a table where the keys are arbitrary identifiers and the values have the following properties:

  • command: The arguments used to run the tool. The first argument is the path to an executable file. Arguments can contain the substring $path, which will be replaced with the repo-relative path of the file being fixed. It is useful to provide the path to tools that include the path in error messages, or behave differently based on the directory or file name.
  • patterns: Determines which files the tool will affect. If this list is empty, no files will be affected by the tool. If there are multiple patterns, the tool is applied only once to each file in the union of the patterns.
  • enabled: Enables or disables the tool. If omitted, the tool is enabled. This is useful for defining disabled tools in user configuration that can be enabled in individual repositories with one config setting.

For example, the following configuration defines how two code formatters (clang-format and black) will apply to three different file extensions (.cc, .h, and .py):

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

Execution order of tools that affect the same file is deterministic, but currently unspecified, and may change between releases. If two tools affect the same file, the second tool to run will receive its input from the output of the first tool.

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

Arguments:
  • <FILESETS> — Fix only these paths
Options:
  • -s, --source <REVSETS> — Fix files in the specified revision(s) and their descendants. If no revisions are specified, this defaults to the revsets.fix setting, or reachable(@, mutable()) if it is not set
  • --include-unchanged-files — Fix unchanged files in addition to changed ones. If no paths are specified, all files in the repo will be fixed

jj git

Commands for working with Git remotes and the underlying Git repo

See this comparison, including a table of commands.

Usage: jj git <COMMAND>

Subcommands:
  • clone — Create a new repo backed by a clone of a Git repo
  • export — Update the underlying Git repo with changes made in the repo
  • fetch — Fetch from a Git remote
  • import — Update repo with changes made in the underlying Git repo
  • init — Create a new Git backed repo
  • push — Push to a Git remote
  • remote — Manage Git remotes
  • root — Show the underlying Git directory of a repository using the Git backend

jj git clone

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

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

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

Arguments:

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

    Local path will be resolved to absolute form.

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

Options:

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

    Default value: origin

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

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

jj git export

Update the underlying Git repo with changes made in the repo

Usage: jj git export

jj git fetch

Fetch from a Git remote

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

Usage: jj git fetch [OPTIONS]

Options:

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

    By default, the specified name matches exactly. Use glob: prefix to expand * as a glob, e.g. --branch 'glob:push-*'. Other wildcard characters such as ? are not supported.

    Default value: glob:*

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

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

    By default, the specified remote names matches exactly. Use a string pattern, e.g. --remote 'glob:*', to select remotes using patterns.

  • --all-remotes — Fetch from all remotes

jj git import

Update repo with changes made in the underlying Git repo

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

Usage: jj git import

jj git init

Create a new Git backed repo

Usage: jj git init [OPTIONS] [DESTINATION]

Arguments:

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

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

    Default value: .

Options:

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

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

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

  • --git-repo <GIT_REPO> — Specifies a path to an existing git repository to be used as the backing git repo for the newly created jj repo.

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

    This option is mutually exclusive with --colocate.

jj git push

Push to a Git remote

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

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

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

Usage: jj git push [OPTIONS]

Options:

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

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

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

    By default, the specified name matches exactly. Use glob: prefix to select bookmarks by wildcard pattern.

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

  • --tracked — Push all tracked bookmarks

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

  • --deleted — Push all deleted bookmarks

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

  • -N, --allow-new — Allow pushing new bookmarks

    Newly-created remote bookmarks will be tracked automatically.

    This can also be turned on by the git.push-new-bookmarks setting. If it's set to true, --allow-new is no-op.

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

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

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

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

  • -c, --change <REVSETS> — Push this commit by creating a bookmark based on its change ID (can be repeated)

    The created bookmark will be tracked automatically. Use the git.push-bookmark-prefix setting to change the prefix for generated names.

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

    Does not require --allow-new.

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

jj git remote

Manage Git remotes

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

Usage: jj git remote <COMMAND>

Subcommands:
  • add — Add a Git remote
  • list — List Git remotes
  • remove — Remove a Git remote and forget its bookmarks
  • rename — Rename a Git remote
  • set-url — Set the URL of a Git remote

jj git remote add

Add a Git remote

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

Arguments:
  • <REMOTE> — The remote's name

  • <URL> — The remote's URL or path

    Local path will be resolved to absolute form.

jj git remote list

List Git remotes

Usage: jj git remote list

jj git remote remove

Remove a Git remote and forget its bookmarks

Usage: jj git remote remove <REMOTE>

Arguments:
  • <REMOTE> — The remote's name

jj git remote rename

Rename a Git remote

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

Arguments:
  • <OLD> — The name of an existing remote
  • <NEW> — The desired name for old

jj git remote set-url

Set the URL of a Git remote

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

Arguments:
  • <REMOTE> — The remote's name

  • <URL> — The desired URL or path for remote

    Local path will be resolved to absolute form.

jj git root

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

Usage: jj git root

jj help

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

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

Arguments:
  • <COMMAND> — Print help for the subcommand(s)
Options:

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

    Possible values:

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

jj interdiff

Compare the changes of two commits

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

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

Arguments:
  • <FILESETS> — Restrict the diff to these paths
Options:
  • -f, --from <REVSET> — Show changes from this revision
  • -t, --to <REVSET> — Show changes to this revision
  • -s, --summary — For each path, show only whether it was modified, added, or deleted
  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • -w, --ignore-all-space — Ignore whitespace when comparing lines
  • -b, --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj log

Show revision history

Renders a graphical view of the project's history, ordered with children before parents. By default, the output only includes mutable revisions, along with some additional revisions for context. Use jj log -r :: to see all revisions. See [jj help -k revsets] for information about the syntax.

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

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

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

Arguments:
  • <FILESETS> — Show revisions modifying the given paths
Options:

  • -r, --revisions <REVSETS> — Which revisions to show

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

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

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

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

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

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

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

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

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

  • -p, --patch — Show patch

  • -s, --summary — For each path, show only whether it was modified, added, or deleted
  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj new

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

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

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

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

Arguments:

  • <REVSETS> — Parent(s) of the new change

    Default value: @

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

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

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

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

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

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

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

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

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

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

    --after and --before can be combined.

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

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

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

jj next

Move the working-copy commit to the child revision

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

For example, when the offset is 1:

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

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

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

Usage: jj next [OPTIONS] [OFFSET]

Arguments:

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

    Default value: 1

Options:

  • -e, --edit — Instead of creating a new working-copy commit on top of the target commit (like jj new), edit the target commit directly (like jj edit)

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

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

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

  • --conflict — Jump to the next conflicted descendant

jj operation

Commands for working with the operation log

See the operation log documentation for more information.

Usage: jj operation <COMMAND>

Command Alias: op

Subcommands:
  • abandon — Abandon operation history
  • diff — Compare changes to the repository between two operations
  • log — Show the operation log
  • restore — Create a new operation that restores the repo to an earlier state
  • show — Show changes to the repository in an operation
  • undo — Create a new operation that undoes an earlier operation

jj operation abandon

Abandon operation history

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

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

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

Usage: jj operation abandon <OPERATION>

Arguments:
  • <OPERATION> — The operation or operation range to abandon

jj operation diff

Compare changes to the repository between two operations

Usage: jj operation diff [OPTIONS]

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

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

    If the previous version has different parents, it will be temporarily rebased to the parents of the new version, so the diff is not contaminated by unrelated changes.

  • -s, --summary — For each path, show only whether it was modified, added, or deleted

  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj operation log

Show the operation log

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

Usage: jj operation log [OPTIONS]

Options:

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

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

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

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

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

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

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

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

    If the previous version has different parents, it will be temporarily rebased to the parents of the new version, so the diff is not contaminated by unrelated changes.

  • -s, --summary — For each path, show only whether it was modified, added, or deleted

  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj operation restore

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

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

Usage: jj operation restore [OPTIONS] <OPERATION>

Arguments:

  • <OPERATION> — The operation to restore to

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

Options:

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

    This option is EXPERIMENTAL.

    Default values: repo, remote-tracking

    Possible values:

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

jj operation show

Show changes to the repository in an operation

Usage: jj operation show [OPTIONS] [OPERATION]

Arguments:

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

    Default value: @

Options:
  • --no-graph — Don't show the graph, show a flat list of modified changes

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

    If the previous version has different parents, it will be temporarily rebased to the parents of the new version, so the diff is not contaminated by unrelated changes.

  • -s, --summary — For each path, show only whether it was modified, added, or deleted

  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines

jj operation undo

Create a new operation that undoes an earlier operation

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

Usage: jj operation undo [OPTIONS] [OPERATION]

Arguments:

  • <OPERATION> — The operation to undo

    Use jj op log to find an operation to undo.

    Default value: @

Options:

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

    This option is EXPERIMENTAL.

    Default values: repo, remote-tracking

    Possible values:

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

jj parallelize

Parallelize revisions by making them siblings

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

3 | 3 2 / \ | -> 1 2 1 \ / | 0 0

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

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

Usage: jj parallelize [REVSETS]...

Arguments:
  • <REVSETS> — Revisions to parallelize

jj prev

Change the working copy revision relative to the parent revision

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

For example, when the offset is 1:

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

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

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

Usage: jj prev [OPTIONS] [OFFSET]

Arguments:

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

    Default value: 1

Options:

  • -e, --edit — Edit the parent directly, instead of moving the working-copy commit

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

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

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

  • --conflict — Jump to the previous conflicted ancestor

jj rebase

Move revisions to different parent(s)

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

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

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

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

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

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

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

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

Specifying which revisions to rebase

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Specifying where to rebase the revisions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Options:

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

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

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

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

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

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

  • -r, --revisions <REVSETS> — Rebase the given revisions, rebasing descendants onto this revision's parent(s)

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

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

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

  • -A, --insert-after <REVSETS> [alias: after] — The revision(s) to insert after (can be repeated to create a merge commit)
  • -B, --insert-before <REVSETS> [alias: before] — The revision(s) to insert before (can be repeated to create a merge commit)
  • --skip-emptied — If true, when rebasing would produce an empty commit, the commit is abandoned. It will not be abandoned if it was already empty before the rebase. Will never skip merge commits with multiple non-empty parents

jj resolve

Resolve conflicted files with an external merge tool

Only conflicts that can be resolved with a 3-way merge are supported. See docs for merge tool configuration instructions. External merge tools will be invoked for each conflicted file one-by-one until all conflicts are resolved. To stop resolving conflicts, exit the merge tool without making any changes.

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

Usage: jj resolve [OPTIONS] [FILESETS]...

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

  • -r, --revision <REVSET>

    Default value: @

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

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

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

jj restore

Restore paths from another revision

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

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

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

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

Usage: jj restore [OPTIONS] [FILESETS]...

Arguments:
  • <FILESETS> — Restore only these paths (instead of all paths)
Options:
  • -f, --from <REVSET> — Revision to restore from (source)
  • -t, --into <REVSET> [alias: to] — Revision to restore into (destination)

  • -c, --changes-in <REVSET> — Undo the changes in a revision as compared to the merge of its parents.

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

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

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

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

jj revert

Apply the reverse of the given revision(s)

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

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

Usage: jj revert [OPTIONS] <--destination <REVSETS>|--insert-after <REVSETS>|--insert-before <REVSETS>>

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

jj root

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

Usage: jj root

jj show

Show commit description and changes in a revision

Usage: jj show [OPTIONS] [REVSET]

Arguments:

  • <REVSET> — Show changes in this revision, compared to its parent(s)

    Default value: @

Options:

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

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

  • -s, --summary — For each path, show only whether it was modified, added, or deleted

  • --stat — Show a histogram of the changes

  • --types — For each path, show only its type before and after

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

  • --name-only — For each path, show only its path

    Typically useful for shell commands like: jj diff -r @- --name-only | xargs perl -pi -e's/OLD/NEW/g

  • --git — Show a Git-format diff

  • --color-words — Show a word-level diff with changes indicated only by color
  • --tool <TOOL> — Generate diff by external command
  • --context <CONTEXT> — Number of lines of context to show
  • --ignore-all-space — Ignore whitespace when comparing lines
  • --ignore-space-change — Ignore changes in amount of whitespace when comparing lines
  • --no-patch — Do not show the patch

jj sign

Cryptographically sign a revision

This command requires configuring a commit signing backend.

Usage: jj sign [OPTIONS]

Options:

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

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

    Note that revisions are always re-signed.

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

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

jj simplify-parents

Simplify parent edges for the specified revision(s).

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

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

Usage: jj simplify-parents [OPTIONS]

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

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

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

jj sparse

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

Usage: jj sparse <COMMAND>

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

jj sparse edit

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

Usage: jj sparse edit

jj sparse list

List the patterns that are currently present in the working copy

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

Usage: jj sparse list

jj sparse reset

Reset the patterns to include all files in the working copy

Usage: jj sparse reset

jj sparse set

Update the patterns that are present in the working copy

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

Usage: jj sparse set [OPTIONS]

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

jj split

Split a revision in two

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

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

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

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

Arguments:
  • <FILESETS> — Files matching any of these filesets are put in the first commit
Options:

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

    This is the default if no filesets are provided.

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

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

    Default value: @

  • -p, --parallel — Split the revision into two parallel revisions instead of a parent and child

jj squash

Move changes from a revision into another revision

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

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

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

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

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

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

Arguments:
  • <FILESETS> — Move only changes to these paths (instead of all paths)
Options:
  • -r, --revision <REVSET> — Revision to squash into its parent (default: @)
  • -f, --from <REVSETS> — Revision(s) to squash from (default: @)
  • -t, --into <REVSET> [alias: to] — Revision to squash into (default: @)
  • -m, --message <MESSAGE> — The description to use for squashed revision (don't open editor)
  • -u, --use-destination-message — Use the description of the destination revision and discard the description(s) of the source revision(s)
  • -i, --interactive — Interactively choose which parts to squash
  • --tool <NAME> — Specify diff editor to be used (implies --interactive)
  • -k, --keep-emptied — The source revision will not be abandoned

jj status

Show high-level repo status

This includes:

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

Usage: jj status [FILESETS]...

Command Alias: st

Arguments:
  • <FILESETS> — Restrict the status display to these paths

jj tag

Manage tags

Usage: jj tag <COMMAND>

Subcommands:
  • list — List tags

jj tag list

List tags

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

Command Alias: l

Arguments:

  • <NAMES> — Show tags whose local name matches

    By default, the specified name matches exactly. Use glob: prefix to select tags by wildcard pattern.

Options:

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

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

jj util

Infrequently used commands such as for generating shell completions

Usage: jj util <COMMAND>

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

jj util completion

Print a command-line-completion script

Apply it by running one of these:

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

Usage: jj util completion [SHELL]

Arguments:

  • <SHELL>

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

jj util config-schema

Print the JSON schema for the jj TOML config format

Usage: jj util config-schema

jj util exec

Execute an external command via jj

This is useful for arbitrary aliases.

!! WARNING !!

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

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

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

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

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

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

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

Arguments:
  • <COMMAND> — External command to execute
  • <ARGS> — Arguments to pass to the external command

jj util gc

Run backend-dependent garbage collection.

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

Previous versions of a change that are reachable via the evolution log are not garbage-collected.

Usage: jj util gc [OPTIONS]

Options:

  • --expire <EXPIRE> — Time threshold

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

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

jj util install-man-pages

Install Jujutsu's manpages to the provided path

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

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

jj util markdown-help

Print the CLI help for all subcommands in Markdown

Usage: jj util markdown-help

jj undo

Undo an operation (shortcut for jj op undo)

Usage: jj undo [OPTIONS] [OPERATION]

Arguments:

  • <OPERATION> — The operation to undo

    Use jj op log to find an operation to undo.

    Default value: @

Options:

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

    This option is EXPERIMENTAL.

    Default values: repo, remote-tracking

    Possible values:

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

jj unsign

Drop a cryptographic signature

See also commit signing docs.

Usage: jj unsign [OPTIONS]

Options:
  • -r, --revisions <REVSETS> — What revision(s) to unsign

jj version

Display version information

Usage: jj version

jj workspace

Commands for working with workspaces

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

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

Each workspace also has own sparse patterns.

Usage: jj workspace <COMMAND>

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

jj workspace add

Add a workspace

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

Usage: jj workspace add [OPTIONS] <DESTINATION>

Arguments:
  • <DESTINATION> — Where to create the new workspace
Options:

  • --name <NAME> — A name for the workspace

    To override the default, which is the basename of the destination directory.

  • -r, --revision <REVSETS> — A list of parent revisions for the working-copy commit of the newly created workspace. You may specify nothing, or any number of parents.

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

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

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

    Default value: copy

    Possible values:

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

jj workspace forget

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

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

Usage: jj workspace forget [WORKSPACES]...

Arguments:
  • <WORKSPACES> — Names of the workspaces to forget. By default, forgets only the current workspace

jj workspace list

List workspaces

Usage: jj workspace list

jj workspace rename

Renames the current workspace

Usage: jj workspace rename <NEW_WORKSPACE_NAME>

Arguments:
  • <NEW_WORKSPACE_NAME> — The name of the workspace to update to

jj workspace root

Show the current workspace root directory

Usage: jj workspace root

jj workspace update-stale

Update a workspace that has become stale

See the stale working copy documentation for more information.

Usage: jj workspace update-stale

This document was generated automatically by clap-markdown.

Read Entire Article
  1. Homepage
  2. Technology
  3. jj Workspace

Related

Return YouTube Dislike" Chrome Extension Injecting Ads

Return YouTube Dislike" Chrome Extension Injecting Ads

14 minutes ago 0
mRNA Vaccines and Immuno-Oncology: Good News by Derek Lowe

mRNA Vaccines and Immuno-Oncology: Good News by Derek Lowe

16 minutes ago 0
Redwood Materials Tops $6B Valuation in Funding Round

Redwood Materials Tops $6B Valuation in Funding Round

17 minutes ago 0
Hostinger Web Hosting