.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.TH jj-gerrit-upload 1  "upload " 
.SH NAME
jj\-gerrit\-upload \- Upload changes to Gerrit for code review, or update existing changes
.SH SYNOPSIS
\fBjj gerrit upload\fR [\fB\-r\fR|\fB\-\-revision\fR] [\fB\-R\fR|\fB\-\-repository\fR] [\fB\-b\fR|\fB\-\-remote\-branch\fR] [\fB\-\-ignore\-working\-copy\fR] [\fB\-\-no\-integrate\-operation\fR] [\fB\-\-remote\fR] [\fB\-\-ignore\-immutable\fR] [\fB\-n\fR|\fB\-\-dry\-run\fR] [\fB\-\-at\-operation\fR] [\fB\-\-reviewer\fR] [\fB\-\-cc\fR] [\fB\-\-debug\fR] [\fB\-\-color\fR] [\fB\-l\fR|\fB\-\-label\fR] [\fB\-\-quiet\fR] [\fB\-\-topic\fR] [\fB\-\-hashtag\fR] [\fB\-\-no\-pager\fR] [\fB\-\-config\fR] [\fB\-m\fR|\fB\-\-message\fR] [\fB\-\-config\-file\fR] [\fB\-\-edit\fR] [\fB\-\-wip\fR] [\fB\-\-ready\fR] [\fB\-\-private\fR] [\fB\-\-remove\-private\fR] [\fB\-\-publish\-comments\fR] [\fB\-\-no\-publish\-comments\fR] [\fB\-\-notify\fR] [\fB\-\-submit\fR] [\fB\-\-skip\-validation\fR] [\fB\-\-merged\fR] [\fB\-\-ignore\-attention\-set\fR] [\fB\-\-deadline\fR] [\fB\-\-custom\fR] [\fB\-o\fR|\fB\-\-option\fR] [\fB\-\-trace\fR] [\fB\-h\fR|\fB\-\-help\fR] 
.SH DESCRIPTION
Upload changes to Gerrit for code review, or update existing changes
.PP
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.
.PP
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.
.PP
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 = \*(Aq\*(Aq\*(Aq
if(
  !trailers.contains_key("Change\-Id"),
  format_gerrit_change_id_trailer(self)
)
\*(Aq\*(Aq\*(Aq
```
.PP
Also see the [Jujutsu docs on Gerrit].
.PP
[Jujutsu docs on Gerrit]: https://docs.jj\-vcs.dev/latest/gerrit
.SH OPTIONS
.TP
\fB\-r\fR, \fB\-\-revision\fR \fI<REVSETS>\fR
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 \*(Aqmutable()::foo\*(Aq`.

If this is not provided, `@` will be uploaded if it has a description, and `@\-` will be uploaded otherwise.
.TP
\fB\-b\fR, \fB\-\-remote\-branch\fR \fI<REMOTE_BRANCH>\fR
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.
.TP
\fB\-\-remote\fR \fI<REMOTE>\fR
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.
.TP
\fB\-n\fR, \fB\-\-dry\-run\fR
Only display what will change on the remote; do not push changes to Gerrit
.TP
\fB\-\-reviewer\fR \fI<REVIEWER>\fR
Add these emails as a reviewer (can be repeated)
.TP
\fB\-\-cc\fR \fI<CC>\fR
CC these emails on the change (can be repeated)
.TP
\fB\-l\fR, \fB\-\-label\fR \fI<LABEL>\fR
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.
.TP
\fB\-\-topic\fR \fI<TOPIC>\fR
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.
.TP
\fB\-\-hashtag\fR \fI<HASHTAG>\fR
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.
.TP
\fB\-m\fR, \fB\-\-message\fR \fI<MESSAGE>\fR
The description for the patch set
.TP
\fB\-\-edit\fR
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\*(Aqt 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.
.TP
\fB\-\-wip\fR
Mark the change as WIP (work in progress)

See https://gerrit\-review.googlesource.com/Documentation/intro\-user.html#wip.
.TP
\fB\-\-ready\fR
Mark the change as ready (no longer work in progress)
.TP
\fB\-\-private\fR
Mark the change as private

See https://gerrit\-review.googlesource.com/Documentation/intro\-user.html#private\-changes.
.TP
\fB\-\-remove\-private\fR
Unmark the change as private
.TP
\fB\-\-publish\-comments\fR
Publish draft comments for the given change
.TP
\fB\-\-no\-publish\-comments\fR
Do not publish draft comments for the given change

This is only useful if the user has configured Gerrit to publish comments by default.
.TP
\fB\-\-notify\fR \fI<NOTIFY>\fR
Who to email notifications to (defaults to all)
.br

.br
\fIPossible values:\fR
.RS 14
.IP \(bu 2
none: No emails
.IP \(bu 2
owner: Only the change owner is notified
.IP \(bu 2
owner\-reviewers: Only the change owner and reviewers will be notified
.IP \(bu 2
all: All relevant users, including owner, reviewers, cc\*(Aqd, users that have starred the change, and users who have configured a watch on files in the change
.RE
.TP
\fB\-\-submit\fR
Directly submit the changes, bypassing code review
.TP
\fB\-\-skip\-validation\fR
When \-\-submit is provided, skip performing validations
.TP
\fB\-\-merged\fR
Create a new change, even if the change has already been merged
.TP
\fB\-\-ignore\-attention\-set\fR
Do not modify the attention set upon uploading
.TP
\fB\-\-deadline\fR \fI<DEADLINE>\fR
The deadline after which the push should be aborted
.TP
\fB\-\-custom\fR \fI<CUSTOM>\fR
Send the following custom keyed values to Gerrit (can be repeated)

See https://gerrit\-review.googlesource.com/Documentation/user\-upload.html#custom_keyed_values
.TP
\fB\-o\fR, \fB\-\-option\fR \fI<OPTION>\fR
Send a `git push \-o` option (can be repeated)
.TP
\fB\-\-trace\fR \fI<TRACE>\fR
For debugging Gerrit

See https://gerrit\-review.googlesource.com/Documentation/user\-upload.html#trace
.TP
\fB\-h\fR, \fB\-\-help\fR
Print help (see a summary with \*(Aq\-h\*(Aq)
.SH "GLOBAL OPTIONS"
.TP
\fB\-R\fR, \fB\-\-repository\fR \fI<REPOSITORY>\fR
Path to repository to operate on

By default, Jujutsu searches for the closest .jj/ directory in an ancestor of the current working directory.
.TP
\fB\-\-ignore\-working\-copy\fR
Don\*(Aqt snapshot the working copy, and don\*(Aqt 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`.
.TP
\fB\-\-no\-integrate\-operation\fR
Run the command as usual but don\*(Aqt 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.
.TP
\fB\-\-ignore\-immutable\fR
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.
.TP
\fB\-\-at\-operation\fR \fI<AT_OPERATION>\fR
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\*(Aqs rarely a reason to do that, but it is possible.
.TP
\fB\-\-debug\fR
Enable debug logging
.TP
\fB\-\-color\fR \fI<WHEN>\fR
When to colorize output
.br

.br
\fIPossible values:\fR
.RS 14
.IP \(bu 2
always
.IP \(bu 2
never
.IP \(bu 2
debug
.IP \(bu 2
auto
.RE
.TP
\fB\-\-quiet\fR
Silence non\-primary command output

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

Warnings and errors will still be printed.
.TP
\fB\-\-no\-pager\fR
Disable the pager
.TP
\fB\-\-config\fR \fI<NAME=VALUE>\fR
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\*(Aqt enclosed by any TOML constructs (such as array notation), quotes can be omitted.
.TP
\fB\-\-config\-file\fR \fI<PATH>\fR
Additional configuration files (can be repeated)