FreeBSD Manual Pages
jj-gerrit-upload(1) General Commands Manual jj-gerrit-upload(1) NAME jj-gerrit-upload - Upload changes to Gerrit for code review, or update ex- isting changes SYNOPSIS jj gerrit upload [-r|--revision] [-R|--repository] [-b|--remote-branch] [--ignore-working-copy] [--no-integrate-operation] [--remote] [--ignore-im- mutable] [-n|--dry-run] [--at-operation] [--reviewer] [--cc] [--debug] [--color] [-l|--label] [--quiet] [--topic] [--hashtag] [--no-pager] [--con- fig] [-m|--message] [--config-file] [--edit] [--wip] [--ready] [--private] [--remove-private] [--publish-comments] [--no-publish-comments] [--notify] [--submit] [--skip-validation] [--merged] [--ignore-attention-set] [--dead- line] [--custom] [-o|--option] [--trace] [-h|--help] DESCRIPTION Upload changes to Gerrit for code review, or update existing changes. Uploading in a set of revisions to Gerrit creates a single "change" for each revision included in the revset. These changes are then available for review on your Gerrit instance. Note: The Gerrit commit Id may not match that of your local commit Id, since we add a `Change-Id` footer to the commit message if one does not al- ready exist. This ID is based off the jj Change-Id, but is not the same. 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: this command takes 1-or-more revsets arguments, each of which can re- solve to multiple revisions; so you may post trees or ranges of commits to Gerrit for review all at once. OPTIONS -r, --revision <REVSETS> The revset, selecting which revisions are sent in to Gerrit This can be any arbitrary set of commits. Note that when you push a commit at the head of a stack, all ancestors are pushed too. This means that `jj gerrit upload -r foo` is equivalent to `jj gerrit up- load -r 'mutable()::foo`. If this is not provided, it will check whether @ has a description. * If it does, it will upload @ * Otherwise, it will upload @- -b, --remote-branch <REMOTE_BRANCH> The location where your changes are intended to land This should be a branch on the remote. Can be configured with the `gerrit.default-remote-branch` repository option. --remote <REMOTE> The Gerrit remote to push to Can be configured with the `gerrit.default-remote` repository option as well. This is typically a full SSH URL for your Gerrit instance. -n, --dry-run Do not actually push the 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) Gerrit silently ignores labels not present on your gerrit host. De- faults to +1 if no value is set. Eg. --label=Commit-Queue will set the Commit-Queue label to +1. Eg. --label=Commit-Queue+2 will set it to +2. --topic <TOPIC> Applies a topic to the change See https://gerrit-review.googlesource.com/Documentation/in- tro-user.html#topics. Changes can be grouped by topic, and Gerrit can be configured to submit all changes in a topic together in a single click. --hashtag <HASHTAG> Applies a hashtag to the change (can be repeated) See https://gerrit-review.googlesource.com/Documentation/in- tro-user.html#hashtags. 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 group- ing. Changes with the same hashtags are not necessarily submitted together. -m, --message <MESSAGE> A patch set description for the new patch set --edit Push the change as a change edit To push a change edit the underlying change need to already exist on the gerrit server. Change edits don't immediately create a new patchset, 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 re- place the previous one. --wip Marks the change as WIP (work in progress) See https://gerrit-review.googlesource.com/Documentation/in- tro-user.html#wip. --ready Unmarks the change as WIP (work in progress) --private Marks the change as private See https://gerrit-review.googlesource.com/Documentation/in- tro-user.html#private-changes. --remove-private Unmarks the change as private --publish-comments Publishes any draft comments for the given change --no-publish-comments Disables publishing of any 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 con- figured 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-up- load.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-up- load.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-work- ing-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 opera- tion. 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 `im- mutable_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 opera- tions 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 re- based. 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) upload jj-gerrit-upload(1)
NAME | SYNOPSIS | DESCRIPTION | OPTIONS | GLOBAL OPTIONS
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=jj-gerrit-upload&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>