jj-gerrit-upload(1)

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:

    •   none: No emails

    •   owner: Only the change owner is notified

    •   owner-reviewers: Only the change owner and reviewers will be notified

    •   all: All relevant users, including owner, reviewers, cc'd, users that have starred the change, and users who have configured a watch on files in the change

--submit
    Directly submit the changes, bypassing code review

--skip-validation
    When --submit is provided, skip performing validations

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

--ignore-attention-set
    Do not modify the attention set upon uploading

--deadline <DEADLINE>
    The deadline after which the push should be aborted

--custom <CUSTOM>
    Send the following custom keyed values to Gerrit (can be repeated) See https://gerrit-review.googlesource.com/Documentation/user-upload.html#custom_keyed_values

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

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