NAME

jj-gerrit-upload - Upload changes to Gerrit for code review, or update existing changes

SYNOPSIS

jj gerrit upload [-r|--revision] [-R|--repository] [-b|--remote-branch] [--ignore-working-copy] [--no-integrate-operation] [--remote] [--ignore-immutable] [-n|--dry-run] [--at-operation] [--reviewer] [--cc] [--debug] [--color] [-l|--label] [--quiet] [--topic] [--hashtag] [--no-pager] [--config] [-m|--message] [--config-file] [--edit] [--wip] [--ready] [--private] [--remove-private] [--publish-comments] [--no-publish-comments] [--notify] [--submit] [--skip-validation] [--merged] [--ignore-attention-set] [--deadline] [--custom] [-o|--option] [--trace] [-h|--help]

DESCRIPTION

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

Uploading a set of revisions to Gerrit creates a single "change" for each revision included in the revset and all their mutable ancestors. These changes will then be available for review on your Gerrit instance.

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

Note: Any commit in the given revset that does not have a `Change-Id` trailer will have one generated based on the Jujutsu change ID. This trailer is only added to the uploaded commit, which means the resulting commit ID uploaded to Gerrit may not match your local commit ID. As a result, you may encounter divergence when you fetch a merged change into your local repo. To address this, you can abandon your local change or rebase it on top of trunk with `jj rebase --skip-emptied ...`, which will resolve the divergence. Alternatively, you can add the following to your Jujutsu config to add `Change-Id` trailers to your local commits automatically before `jj gerrit upload` does: ```toml [templates] commit_trailers = ''' if(
!trailers.contains_key("Change-Id"),
format_gerrit_change_id_trailer(self) ) ''' ```

Also see the [Jujutsu docs on Gerrit].

[Jujutsu docs on Gerrit]: https://docs.jj-vcs.dev/latest/gerrit

OPTIONS

-r, --revision <REVSETS>

The revisions to upload to Gerrit

All mutable ancestors of specified revisions will also be pushed. This means that `jj gerrit upload -r foo` is equivalent to `jj gerrit upload -r 'mutable()::foo'`.

If this is not provided, `@` will be uploaded if it has a description, and `@-` will be uploaded otherwise.

-b, --remote-branch <REMOTE_BRANCH>

The location where your changes are intended to land

This should be a branch on the remote. The default is the `gerrit.default-remote-branch` setting.

--remote <REMOTE>

The Gerrit remote to push to

This can point to any configured Git remote, or can be a full SSH URL. The default is the `gerrit.default-remote` setting.

-n, --dry-run

Only display what will change on the remote; do not push changes to Gerrit

--reviewer <REVIEWER>

Add these emails as a reviewer (can be repeated)

--cc <CC>

CC these emails on the change (can be repeated)

-l, --label <LABEL>

Add the following labels configured by Gerrit (can be repeated)

Each label can have a suffix of the value to set, such as "+2". The default is "+1" if no value is set.

Note that Gerrit silently ignores labels not present on your Gerrit host.

Examples: - `--label=Commit-Queue` will set the `Commit-Queue` label to +1. - `--label=Commit-Queue+2` will set it to +2.

--topic <TOPIC>

Apply a topic to the change

Changes can be grouped by topic, and Gerrit can be configured to submit all changes in a topic together in a single click.

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

--hashtag <HASHTAG>

Apply a hashtag to the change (can be repeated)

Hashtags are freeform strings associated with a change, like on social media platforms. Similar to topics, hashtags can be used to group related changes together, and to search using the `hashtag:` operator. Unlike topics, a change can have multiple hashtags, and they are only used for informational grouping. Changes with the same hashtags are not necessarily submitted together.

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

-m, --message <MESSAGE>

The description for the patch set

--edit

Push the change as a change edit

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

--wip

Mark the change as WIP (work in progress)

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

--ready

Mark the change as ready (no longer work in progress)

--private

Mark the change as private

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

--remove-private

Unmark the change as private

--publish-comments

Publish draft comments for the given change

--no-publish-comments

Do not publish draft comments for the given change

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

--notify <NOTIFY>

Who to email notifications to (defaults to all)

Possible values:

--submit

Directly submit the changes, bypassing code review

--skip-validation

When --submit is provided, skip performing validations

--merged

Create a new change, even if the change has already been merged

--ignore-attention-set

Do not modify the attention set upon uploading

--deadline <DEADLINE>

The deadline after which the push should be aborted

--custom <CUSTOM>

Send the following custom keyed values to Gerrit (can be repeated)

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

-o, --option <OPTION>

Send a `git push -o` option (can be repeated)

--trace <TRACE>

For debugging Gerrit

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

-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

Don't snapshot the working copy, and don't update it

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

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

--no-integrate-operation

Run the command as usual but don't integrate any operations

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

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

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

--ignore-immutable

Allow rewriting immutable commits

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

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

--at-operation <AT_OPERATION>

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:

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