jj-gerrit-upload(1)

📦
version 0.46.0 · 3 versions
, in arch rolling, nixpkgs unstable

🌸 jj-gerrit-upload — bestie's guide to yeeting your code at Gerrit 💅

Okay so this is jj-gerrit-upload(1) from the General Commands Manual, and honestly? It's kind of iconic. It's the jj gerrit upload subcommand, and it's about to become your whole personality.

✨ 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. That's the whole ~vibe~.

So here's the tea ☕: when you upload a set of revisions to Gerrit, it creates a single "change" for each revision included in the revset — plus all their mutable ancestors, bestie. Those changes then show up all pretty and ready for review on your Gerrit instance. 👑

If a change already exists for a given revision (i.e. it contains the same Change-Id), then this command just updates the contents of that existing change so everything matches. No duplicate chaos. We love a clean update. ✨

Important heads-up, no cap: any commit in the given revset that does not have a Change-Id trailer will have one generated based on the Jujutsu change ID. That trailer is only added to the uploaded commit — which means the resulting commit ID uploaded to Gerrit may not match your local commit ID. 😭 So yeah, you may encounter divergence when you fetch a merged change back into your local repo. To fix that, you can abandon your local change, or rebase it on top of trunk with jj rebase --skip-emptied ..., which will resolve the divergence. 🫶

Alternatively — and this is the lowkey genius move — you can add the following to your Jujutsu config, so Change-Id trailers get added to your local commits automatically before jj gerrit upload even does its thing:

[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 🌈

Buckle up, there are a lot of them and every single one is here, fr fr.

  • -r, --revision <REVSETS> — The revisions to upload to Gerrit.

All mutable ancestors of the specified revisions will also be pushed. Which means jj gerrit upload -r foo is literally equivalent to jj gerrit upload -r 'mutable()::foo'. Same thing, different font. 💫

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 it 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. Perfect for the "let me just look first" girlies. 👀
  • --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.

Heads up: Gerrit silently ignores labels that aren't present on your Gerrit host. Rude, but okay. 🙈

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. One click. Iconic. 🖱️✨

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're 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. Say it with your chest. 💬
  • --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 — they need to be published from the web UI first. There can only be one edit for each change, and pushing a new change edit will replace the previous one. So don't get attached. 💔

  • --wip — Mark the change as WIP (work in progress). We respect the process. 🚧

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

  • --ready — Mark the change as ready (no longer work in progress). Glow up complete. 🌟
  • --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. Coming out of hiding. 🦋
  • --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. Silence. Peace. 🕊️
  • 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 folks, users that have starred the change, and users who have configured a watch on files in the change. Everyone gets the ping. 📣
  • --submit — Directly submit the changes, bypassing code review. Straight to main, no notes. 🔥
  • --skip-validation — When --submit is provided, skip performing validations. Living dangerously. 💀
  • --merged — Create a new change, even if the change has already been merged.
  • --ignore-attention-set — Do not modify the attention set upon uploading. Leave them be. 🙅‍♀️
  • --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 ✨

These ones work everywhere, bestie — every jj command, every time. They're like the setting spray of your command: not the moment itself, but it holds everything together. 💅

  • -R, --repository <REPOSITORY> — the path to the repo you wanna operate on 🫶

Okay so by default, Jujutsu is giving very "I'll find it myself" energy: it searches for the closest .jj/ directory in an ancestor of the current working directory. So like, wherever you are, it walks up until it finds your repo. Iconic behavior honestly.

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

So normally Jujutsu snapshots the working copy at the beginning of every command. Every single one. And the working copy also gets updated at the end of the command, if the command modified the working-copy commit (@).

But if you want to avoid snapshotting the working copy and instead see a possibly stale working-copy commit, that's literally what --ignore-working-copy is for. Super useful e.g. in a command prompt — especially if you've got another process committing the working copy behind your back. 😭

Also lowkey important: loading the repository at a specific operation with --at-operation implies --ignore-working-copy. It's automatic, no cap.

  • --no-integrate-operation — run the command as usual but don't integrate any operations 💀

When you pass this, the operations will still be created as usual, but they will not be integrated to the operation log. The working copy also won't be updated. So the operation exists, it's just not in the group chat yet.

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. So many options, all valid, all slaying. ✨

⚠️ Heads up bestie: this does not prevent side effects outside the repo. For example, jj git push --no-integrate-operation will still perform the push. The push is happening. The operation just isn't logged. Fr fr, keep that in mind.
  • --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. Main character energy, but make it dangerous.

Careful though — this option only affects the check. It does not affect the immutable_heads() revset or the immutable template keyword. Those are staying exactly as they are. 💅

  • --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. It's giving time travel, honestly. 🦋

--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 — Jujutsu will figure out the rest, iykyk.

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

And yes — 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. Not me saying don't, just saying… there's rarely a reason. 😭

  • --debug — enable debug logging 🔍

For when you need to see everything. Your girl is being verbose.

  • --color <WHEN> — when to colorize output 🌈

Possible values:

  • always
  • never
  • debug
  • auto

Pick your vibe check. always for the full rainbow, never for the minimalist era, auto to let the terminal decide for you. 🎀

  • --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. Just the facts, no commentary.

Warnings and errors will still be printed though. Safety first, always. 💖

  • --no-pager — disable the pager 🚫

No more output getting swallowed into less. Sometimes you just want it all dumped straight into your terminal and that's valid.

  • --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. And if the string value isn't enclosed by any TOML constructs (such as array notation), quotes can be omitted. So you can be a little loose with it, but not too loose. Periodt.

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

Yep. Files. Multiple of them. Repeating is allowed. Go off. 🫶

💅 And that's the whole page, bestie — you're officially caught up on jj-gerrit-upload(1).

Signing off from the upload corner of the man page universe, dated and versioned by the fine folks who ship jj-gerrit-upload(1). Mwah. 💖✨🎀

📦 where this page comes from